| |
A Primer on Workforce Solutions
When we speak of Workforce Solutions, we refer to the combination of a business management application and a data dispatch system.
A wide range of workforce automation applications are available for virtually every vertical market, including Field Service, Package Delivery, Property Management, Para-transit, Taxi, Limousine, Airport Shuttle and Towing, EMS, etc.
 Most are highly specialized to address the needs of one particular vertical or even sub-vertical industry. For example, the functionality required by an Overnight Courier is substantially different than that required by a Same-Day Express Courier. Similarly, the decision criteria or rules by which a job is dispatched to a given driver in a Taxi company are quite different as they would be for a Limousine company.
In spite of the unique aspects of each vertical market, the fundamental building blocks of an end-to-end business management solution are very much similar. The following two tables define the basic database structure and software modules required by virtually all service companies that require an end-to-end solution.
Database Structure
| Account Database |
Master list of customers that pay for tasks performed |
| Location Database |
Master list of job, delivery and landmark locations |
| Asset Database |
List of vehicles and equipment and associated details |
| User Database |
List of authorized drivers and office personnel with access rights |
| Attribute Database |
List of vehicle, account and user qualifications for decision making |
| Rating Database |
Pricing matrix based on services, service levels and locations |
| Commission Database |
Table of driver / worker variable remuneration formulas |
| Item Database |
Parts or inventory items to be sold to a customer, with prices |
| Contact Database |
Master list of customer contacts and their preferences |
| Zone Database |
Master list of logical or geographic zones by which work is assigned |
| Job Database |
Dynamic records of actual work performed |
| Configuration Data |
Customer specific configuration tables, preferences, rules, reports |
Software Modules
| Order Entry |
Call taking screen for entering new orders, editing existing orders |
| Dispatching |
Scheduling and dispatching screen for assigning and monitoring work |
| Pricing / Rating |
Often incorporated into order entry, allows for job pricing |
| Invoicing A/R |
Module for generating customer invoicing and posting to GL |
| Accounting |
Integrated General Ledger or export / batch to external accounting |
| Wireless Dispatch |
Module for configuring and assigning work over wireless medium |
| Reporting |
Module for generating reports on productivity, monitoring quality |
 As can be readily seen in these tables, there is a great deal of similarity in the underlying modular structure of these applications, regardless of the vertical markets they serve. Understanding this is like stepping away from the trees and seeing the forest come into view. When considering which business solution is the most prudent for a particular organization, understanding the underlying structure of these systems helps us get past the bewildering array of features to identify the fundamental differences that actually are important to us.
The fundamental differences lay primarily in the application rules (vertical market driven) and in the application architecture. To briefly explain, the application rules are those logical instruction sets within the software that are used to fine tune the fundamental software modules to a particular company or industry's needs. For example, the rating module in a courier application might use package weight, service level and distance factors in determining the price of a delivery, whereas the rating module in a Limousine company may use vehicle type, number of passengers, number of stops and the number of hours to determine the cost of a job. The basic function or role of the module is the same - to price the job, but the application rules are completely different. These application rules may differ not just in the rating module, but in many other core modules of the business as well. Hence, the reason why a myriad of software applications are available within each vertical market and why this business is so specialized.
As discussed above, the other fundamental difference from one software solution to the next is its architecture. This includes factors such as its raw programming language, database format and its network architecture. For example, is it written in a Windows compatible Win32 programming language such as Visual Basic or is it written in an older, more rigid legacy or DOS format? Is the database structure written in an advanced client- server architecture with a sequel database to accommodate significant growth capacity or is it a more simple file server or peer-to-peer structure with some database speed or growth limitations? These are important, yet not often understood questions that should be identified when selecting the most appropriate system to meet your company's needs.
Future Quest helps service companies to determine their specific requirements, then presents the fundamental alternatives available, outlining the differences in application architecture and application rules. Trade-offs in functionality, performance and costs are determined so that in informed buying decision can be made.
|
|
