FIELD OF THE INVENTION

The invention relates to a method of managing seasonal work activity. The invention also relates to a national seasonal work database and activity management system.

BACKGROUND TO INVENTION

Worldwide primary producers in horticulture and agriculture are facing increased compliance requirements for good agricultural practice (GAP) and fair labour management. These pressures are being applied from both their customers and from national government. Many countries are facing increased shortages of quality episodic labour, coupled with increased scrutiny of individual labour practices. Any breaches of labour practices of a particular country has the potential to be very damaging to all agriculture and horticulture exports.

Over the years the diverse range of employees in the horticulture industries has been developed on an ad hoc basis with little regard for the skills and attitude required to competently do the job. Recently staff and skills shortage during the harvest season had been addressed on the premise that orchardists are desperate enough to take anybody. The current practice of taking beneficiaries off government payments and putting them into orchards presents risks. There is a threat of the loss of the benefit, meaning that an unwilling and unskilled labour force is harvesting fruit destined for the highly lucrative and increasingly globally competitive export markets. Grower's financial returns are reduced and fewer product is packed due to downgraded fruit through poor harvesting technique, untimely harvest due to workforce shortage, poor pruning techniques earlier in the season or seasonal conditions demanding a rapid deployment of the workforce.

Research into the multicultural demographic of the seasonal workforce has highlighted further issues relating to the exchange and interpretation of information to

ensure compliance at personal and subsequently company level. An understanding of the demographic makeup determined that any technology based solution would have to be simple, secure and reliable while being affordable to those at the start of the supply chain. Complete traceability of the fruit and all associations to the fruit including individuals handling fruit is now an important part of meeting international market requirements.

SUMMARY OF INVENTION

The invention provides a method of managing seasonal workers. The method comprises maintaining a plurality of worker records in computer memory, the worker records each identified by a worker identifier and including respective worker personal details, worker skill data and worker activity preferences; assigning a task request to at least one of the worker records based on a comparison of skill requirements of the task with the respective worker skill data of the worker records; transmitting a job offer message to the worker(s) for which the associated worker record(s) has been assigned the task request; receiving an acceptance message from the worker(s) to which the job request has been transmitted; and adding task completion details to the worker record on completion of at least part of the task.

The invention in another aspect provides a seasonal work activity system comprising a plurality of worker records maintained in computer memory, the worker records each identified by a worker identifier and including respective worker personal details, worker skill data and worker activity preferences; a task assigner configured to enable a user to assign a task request to at least one of the worker records based on a comparison of skill requirements of the task with the respective worker skill data of the worker records; and a job transmittal component configured to transmit a job offer message to the worker(s) for which the associated worker record(s) has been assigned the task request.

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 shows a schematic view of the overall system;

Figure 2 shows a typical worker record;

Figure 3 illustrates a preferred form user interface screen for growers;

Figure 4 illustrates a further preferred form user interface screen for growers;

Figure 5 shows a preferred form job card;

Figure 6 shows the creation of a work offer record;

Figure 7 shows a sample job request message;

Figure 8 illustrates a sample visual code;

Figure 9 shows the relationship between a mobile device and the server in the invention;

Figure 10 expands on the role of the visual code of Figure 8; and

Figure 11 illustrates a typical database schema.

DETAILED DESCRIPTION

Activity management is the process of managing the activities carried out by the viticulture and horticulture industry workers. An example of an activity is a picker picking a bin of apples at a particular location at an established dollar rate. Regulations require record keeping by an increasing number of sources. At present this is difficult due to a wide variance in methodology associated with how activities are currently recorded. The process is therefore error prone.

Stakeholders are those working within the horticulture or viticulture industry.

Stakeholders also include those associated with the horticulture and viticulture industries as service providers. These include accountants and government departments and so on. The stakeholders are formed into several logical groups. These include:

■ those that require an action (for example a grower requiring harvesting);

^■ those that undertake that action (the workers);

^■ those that record the action for processing payment transactions (IRD/banks/accountants);

^■ those that need to match actions against individuals and locations to meet compliance under "community obligations" (for example in New Zealand OSH/ACC and Immigration);

^■ those that collate and measure data associated with activity for the purpose of measuring efficiencies (associations);

^■ those that require access to data for traceability (for example exporters).

Figure 1 shows a schematic overview of a preferred form of system 100 for managing seasonal work activity. It is envisaged that each of the workers 105, the producers or growers 110 and contractors 115 register within the system as described below.

In operation the system obtains from each or at least some of the workers 105 personal details. These personal details include a full name for the worker as well as a preferred name. Further details obtained could include the address if known of the worker, an email address, landline telephone number, mobile phone number, nationality and bank account details.

It is also anticipated that an IRD number, a work permit, documented proof of any relevant skills and proof of identity are also obtained from a worker. It is anticipated that a worker will complete a declaration form outlining the degree of information sharing, worker rights and responsibilities. A worker is then assigned a worker identifier.

Workers are each issued with a mobile device holding a set of Unique Identifiers (personal information keys - PIKs). These can be presented in print (on an ID card) or sent digitally to a mobile device and displayed and read directly from the device. Workers are able to display the appropriate identifier in order to allow a request for information to be accessed or an action to be undertaken.For example:

> an unknown worker may allow a contractor to scan the PIK to access their digital work history or qualifications a worker will allow a field manager to scan a PIK instructing the field managers phone to 'add them to a team for record keeping' .

Figure 2 illustrates a typical worker record 200. A worker record representing the worker is maintained in computer memory within the system 100 along with a plurality of other worker records. The worker records include respective worker personal details 205, worker qualification data 210 and worker activity preferences 215.

Also optionally included are a digital work record and information sharing authorisation data 225. Also included in one form is a worker image (not shown) comprising a graphic electronic image of the worker.

Workers registering with the system will generally be migrant workers and general labourers supplemented with beneficiaries and backpackers during seasonal harvesting periods. This group of workers known as field workers or fruit pickers have historically been described as unskilled however demand for quality fruit requires greater knowledge of fruit production. Many are transient and travel from region to region seeking employment where and when it becomes available. Backpackers and beneficiaries are generally unfit, and are unfamiliar with the understanding of a tree and fruit production and are trained on the spot using export apple crops as their training forum. These workers require a high degree of supervision and tend to be unproductive.

General orchard hands are another category of worker. These people are usually employed for up to twelve months of the year and undertake a broad spectrum of tasks yet have minimal formal qualifications. Their skills are unrecognised with no system available to identify skill and productivity. Some have truck, tractor or ladder experience although most would be unaware of general farm equipment maintenance.

Quality controllers are another category of workers that are given the responsibility of endeavouring to control quality in the field prior to fruit being sent to the packhouse. Given that packhouse packing charges are based upon the percentage of fruit packed, keeping costs at a realistic level depends upon the skills of the quality controller in the field. Quality controllers have usually received training in quality control yet seldom have the supervisory and communication skills necessary to manage the labour force's considerable cultural and ethnic diversity.

Working holiday workers are another category of workers. These workers are categorised by generally having difficulty in establishing direct credit payment systems. Bank accounts are difficult to establish with no fixed abode or utility bill and so it is

often easier for these type of workers to be paid in cash. This leads to failure to pay taxation, poor rates and poor conditions as no record is kept of their activity. Working holiday workers have minimal training and there is a reliance on a workforce that the horticulture industry just hopes will "turn up" each year.

Immigrant workers are prone to be taken advantage of by various parties prior to arrival and then exploited by their own ethnic group once they have arrived in the country. Working holiday workers suffer from a lack of understanding of New Zealand systems such as taxation along with language barriers.

The supervisor is the last category of worker. Supervisors have usually evolved from general orchard hands and have no knowledge or little understanding of the management of people nor have effective communication skills.

In each case it is envisaged that the various skills or lack of skills held by each worker and each category of worker are stored in the worker records as worker skill data. Contractors are then able to build the right mix of workers within a team to optimise each activity undertaken. The system offers a visualisation tool of workers and activities associated to place and product.

A grower is an individual company or other organisation that produces a product in a horticulture or viticulture industry. Referring to Figure 1, a grower 110 accesses the system 100 for example using a standard personal computer with internet access. The grower uses a user name and password that is issued to the grower on registration. All user access is recorded and a full audit trail of modifications is kept. The grower supplies grower details. These grower details include a product type for example apples, kiwifruit or strawberries, a business name and a contact name. Further details could include grower personal details such as a business address, email address, phone number and mobile number. Growers are able to use a template tool to describe the 'place' and associated 'product'. This template enables these details to be inputted into a system that is able to be accessed either through a desktop PC or mobile device.

Individual grower records are maintained in computer memory in a similar format to the worker records described above with reference to Figure 2.

Figure 3 shows a preferred form user interface screen 300 in which a grower is able to make a job offer. The grower assigns a task request to at least one of the worker records. The task request includes task details 305. The task details include one or more location identifiers 310, product types 315 for example apple variety, and activity type 320 for example 'harvest' or 'thin'.

The job request is obtained from a grower. As shown in Figure 3, the preferred form user interface includes place or block descriptions 325 such as number of rows within a block and number of trees within each row, enabling Contractors to allocate the appropriate human resource. Also specified are types of workers required 330 for example harvesters, field managers and so on. Statistics gathered during the operation of the system will enable contractors to identify the optimum team mix to complete task efficiently while identifying further training requirements.

The system maintains a plurality of contractor records in computer memory. These contractor records are in a similar format to the grower records and worker records. The contractor records each include respective unique identifiers and represent contractors 115 in the industry. The contractor records typically include a contractor name, a contact name and address, email address, phone number and mobile number. Growers typically engage contractors to arrange workers. It is envisaged that a list of preferred contractors can be maintained. These preferences determine which contractors are contacted with offers of work from each grower. Growers are then able to view all available contractors or individual workers preferring to work direct for the grower. This creates a space where the entire registered workforce availability across regions and sectors can be visualised enabling improved planning around the various seasonal requirements.

Growers are able to view contractors or individual workers by identifying the preferred requirement fields; these can be by sector (activity), region, size of workforce/available workforce, or skill of workforce. Each contractor is listed on a scale based on the collective value of the workforce created from a value associated to work experience and formal qualifications. This provides an incentive to retain and train each member of the workforce.

Figure 4 shows a preferred form user interface that enables a grower to select a contractor or worker. As shown in Figure 4, the grower is provided with an option to conduct a contractor search 405. The contractor is able to specify several search criteria. These search criteria include region 410 and sector 415. As shown in Figure 4, the grower has selected Marlborough as the region and Viticulture as the sector.

A plurality of contractor records are displayed, for example 420, 425 and 430. Each of these contractor records match the region and sector criteria specified by the grower. A further optional criteria is a preference list. In one embodiment, the grower maintains a preference list of most preferred contractors. In the example shown, contractor 420 is a more highly preferred contractor to contractor 425 and so is displayed more prominently. A preferred form ranking is from left to right with the most prominent on the left hand side. The grower is able to specify a criteria by which the contractors are ordered as indicated at 435. In Figure 4, the grower has selected the preference list as the ordering criteria.

As shown in Figure 4, each contractor has an experience value that represents the sum total of experience in hours held by the workers available to that contractor. Also maintained is a current workforce value representing the number of workers available. As will be clear from Figure 4, contractor 420 and contractor 425 have available to them 65 workers and 33 workers respectively. Contractor 430, on the other hand, is an individual with a workforce of one.

Also shown is the average hours worked per person which is the total hours divided by the current workforce.

One embodiment also displays a qualification rating. This represents the total number of unit standards held in a recognised educational system by each of the workers available to the contractor.

Also displayed is a contractor rating which in one embodiment is the sum of the experience total value and the qualification rating.

Displaying this information enables a grower to select a contractor easily.

In use the grower issues job requests to one or more contractors according to a preference list. The grower specifies the start and end date of the job and describes any information pertinent to the contractor. The number and type of workers required are listed.

A contractor work offer record is then created and saved. Figure 5 illustrates a preferred form job card that is created and sent to a contractor for action. Job card 500 typically includes a narration 505, and a sequence of location identifiers 510, 515, 520 and 525. The job card also includes services required 530 and services and tools supplied 535. The job request embodied in the contractor work offer record is transmitted to one or more contractors as a job offer message. Sometimes a contractor is only able to supply part of the labour requirement and could agree to a partial contract. In other circumstances the contractor simply accepts the work offer message.

The contractor then assigns the task or tasks embodied in the work offer record to one or more worker records, as shown in Figure 6. As shown in Figure 6, a contractor is able to specify a list of preferred contractors for particular jobs. The user interface shown in Figure 6 allows a contractor to search by status 605 and region 610 and enables workers to be sorted by further criteria 615.

Each worker has a status of either unassigned or unavailable so most searches look for workers with a status of unassigned. Most workers specify a region in which they are available. In some cases the worker will not specify any region, indicating they are available to work anywhere. As shown in 610, a region can be specified so that only those workers who are available to work in that region are shown. Where there are different ethnic groups among a group of possible workers, the interface shown in Figure 6 enables a contractor to specify a particular ethnic group or to at least sort available workers by ethnic group to ensure that a group of workers assigned to a job are of the same or at least compatible ethnic groups.

Individual representations of workers are shown, for example 620, 625, 630 and 635. A contractor is able to select a particular individual, for example by clicking a user input device. An individual preferences page 640 of a selected individual is displayed. The contractor then fills particular groups of workers or teams, for example teams 645, 650, 655 and 660 by selecting individual workers and dragging and dropping into a particular team representation.

The assigning is based on a comparison of the skill requirements for a task with the work skill data of the worker records. A job request message is then transmitted to the handheld device of the worker for which the associated worker record has been assigned the task. Figure 7 shows a sample job request message 700 displayed on a handheld device. An acceptance message from the worker is then received from the handheld device to which the job request message has been transmitted. Currently employers are inundated with endless phone calls to and from workers until labour requirements are met.

The system collates the responses from the workers and provides feedback to the contractor. Based on the replies, the contractor could take further manual action such as making phone calls or having the system contact other workers. When the contractor has finished forming a suitable team to meet the requirements, the system responds to the grower.

Once on the job, the daily management of workers and the recording of completed work is a responsibility of on site supervisors. The supervisor, who may or may not also be the contractor, accesses the system via a computer application running on a mobile device operated by the supervisor.

Before a day's activities begin the field manager (supervisor) uses a mobile phone camera to scan each worker's unique identifier or PIK (personal information key). This adds a worker's details to an application running on the mobile device that in turn assigns the worker to a product, place and the appropriate activity. The field manager is then able to either begin recording a start time (for time based payments) or associate each completed task (piece meal payments) to each worker.

Coding data into the visual code enables the use of a common device while minimising the need to key in data thereby reducing errors. The identifier for each action is coded into a visual key and subsequently decoded by an application running on the device. Each visual code contains a prefix. The decoding device must be authorised to access the prefix.

Figure 8 illustrates a sample visual code. The code is selected so that it is not easily distinguishable from other codes by a human reader. The code is designed to be machine readable only. The visual code can be presented in printed form (ID card) or scanned as an image directly from the worker's mobile phone. Each code is able to issue an instruction to the scanning device. This can include: • add me to your team

• access my digital work record

• access my qualifications

• add my contact details to your contacts list

For security; each code holds a prefix so it can only be decoded by the appropriate application held on the phone. Where data is held on a server the URL is

completely hidden e.g. there is no requirement for the user to know or need to enter in the URL.

Using a PIK enables an unknown worker to be identified and immediately entered into a team from a remote location and without need of connectivity.

During the day, the supervisor records the completion of tasks by each worker in the mobile phone application managed by the supervisor. For example, when an apple picker fills a bin of apples, the supervisor records this fact in the application on the phone. The worker is selected from a list of all members in the team and the supervisor scans the bin identification tag that is attached to the bin of apples. The mobile application records the bin number, the date and time completed, against the identification number of the worker.

At the end of each day, the supervisor presses an upload button on the mobile application to send all information recorded through the day to the main system. The server will then notify the supervisor that the action has been successful and remove the data cached on the phone's memory. If the supervisor is out of coverage the phone will automatically send all data once receiving cellular reception. If the supervisor forgets, the phone reminds the supervisor by way of a scheduled alarm.

The system updates the tasks and calculates payment details for the worker. The grower and contractor are also able to view a progress report for the job.

It is envisaged that reports could be generated for example:

■ grower registration invoice detailing the registration of grower orchards;

■ consignment notes showing the consignment of produce to a coldstore or packhouse;

^■ j ob/worker progress showing the current state of any j ob including who completed each task;

^■ invoices from the contractors for completed work.

Contractors are also able to access reports detailing invoices to the grower to bill for the number of bins/rows completed at an agreed rate and the percentage for supervision/quality control work. The contractor is also able to access reports on job/worker progress and a report of jobs showing payments to workers and invoices to growers.

It is envisaged that workers are able to use internet cafes or home desk top machines to view pay packet gross amounts detailing their rate and number and type of tasks complete as well as a complete work history in the form of a CV or digital work history that is updated daily.

Figure 9 illustrates the relationship between the mobile device and the server. The system 900 includes a database server 905. The database server 905 is interfaced to a web server 910 providing a web service. The web service exposes parts of an application model to external devices. The web service 910 is protected by a firewall 915 that prevents unauthorised access to the web service web server 910.

Web server 910 is preferably interfaced to Internet network or networks 910 providing a low cost method of transferring information around system 910.

A desktop application 925 is used to access specific data from the applications model that enables the owner of information to manage and monitor activities performed by workers.

System 910 further includes one or more field manager phones 930. These devices are high end devices that are used to capture locations, activities and workers.

The device 930 interacts with the application model and additional information can be obtained from the application model to manage an activity or worker as required.

System 900 also includes worker phones 935. These phones 935 are standard devices that as a minimum receive and send text messages via an SMS network (not shown) to enable a worker to respond to a job offer. More advanced features are available to workers with high end mobile phones that enable access to an on board camera.

Figure 10 expands on the role of the visual code or sample identifier shown in

Figure 8 as a personal information key. In the system 1000 shown in Figure 10, a field manager high end mobile device 1005 is used to send information collected in the field between the application running on desktop 1025 and the web service web server 1010 via an http or SMS network (not shown) depending on coverage availability.

The field manager 1010 manipulates data stored on phone 1005 by associating workers with activities and performs basic time keeping tasks.

Interaction between the user and the system is achieved using a minimalist approach. Most of the raw information is obtained either via two dimensional symbologies or via SOAP packets from the web service 1010. This is represented at 1015.

Collected information is stored on an on board database server 1020. The application model of the phone is a simplified version of the application model exposed by the web service.

Decoded information useful to the application model is stored 1025, while information for worker verification is used by the application directly.

Encoded information is decoded 1030 via conventional algorithms.

The field manager 1010 phone device 1005 has an on board camera 1035 to capture the two dimensional symbologies that are encoded with information.

Information obtained from 1015 is used to create a SOAP envelope 1040 encapsulating one record and a unique application key 1045. The unique key 1045 is embedded in the phone application when the application is first activated. This is used to verify that the information send to the web service is from a valid user.

Once a SOAP envelope 1040 has been sent and a corresponding positive SOAP response received, the record sent is then purged from the phones database server indicated at 1050.

Information sent between the phone and web service web server are sent as small SOAP packets 1055. The information is parsed and stored locally. As shown at 1060, additional information can be requested from the web service. Information such as predefined worker groups or predefined activities are examples of additional information.

Figure 11 shows a typical database schema detailing the entities and relationships between them. This is a preferred form schema implemented on a central server within system 100.

The foregoing describes the invention including preferred forms thereof. Modifications and improvements as would be obvious to those skilled in the art are intended to be incorporated in the scope hereof, as defined by the accompanying claims.