Skip to content

Customer Implementation Project Guide

Realtime Despatch Software Ltd

Document Version: 4.0.6

Document Built: 2020-10-12

This document and its content is copyright of Realtime Despatch Software Limited. All rights reserved.
You may not, except with our express written permission, distribute, publish or commercially exploit the content.
Any reproduction of part or all of the contents in any form is prohibited.

Home

Welcome

Congratulations! You have chosen OrderFlow to meet your order processing and warehouse management needs.

In the meantime, there's a lot of work to do. This document is intended to provide you with a high-level overview of what to expect over the coming weeks and months, as we help you prepare for Go-Live.

The next chapters provide a summary of the key project phases to expect as we move towards Go-Live. We'll start with a high level overview of the phases that are common to each project we implement.

With each chapter, we will cover each of the phases in more detail, describing the key activities, deliverables, sign-off points.

The intended audience of this document is:

  • customers who have chosen OrderFlow as a solution to the needs of their organisation
  • anyone involved in the task of introducing OrderFlow into your warehouse
  • potential users and administrators of the OrderFlow system

After reading this document, you will hopefully have a good understanding of:

  • the individual elements of an OrderFlow launch project
  • how the project is structured and evolves through the different stages
  • the timing of site visits as well as the key sign off points on the project
  • our basis for costing the project, both planned and unanticipated elements

We recommend that you read this document in full prior to our arranging our first on-site visit with you.

stock allocation and assignment

Project Phases

Once the initial project setup is complete, we can move through the various phases of the project. This chapter gives an overview of the phases; in subsequent chapters we will cover each of these in more detail.

Project Overall

The phases themselves are divided into three groups:

  • Setup Phases: during these phases, work will be undertaken to initiate and define the scope of the project, and to agree on a high level plan for the project.
  • Build Phases: these are the phases during the work to prepare the system for launch, and to do any necessary setup and verification of the environment in which the system will run.
  • Launch Phases: these phases handle the launch and post-launch activity associated with the project.

Deliverables

The tables below show the main deliverables associated with each of the phases.

Setup Phases Deliverables
Project Setup Agreed roles and responsibilities, your dedicated Redmine project and RemoteMan configuration, agreed Rules of Engagement and your vanilla OrderFlow test environment
Project Scoping A Requirements Document, with an itemised summary of your requirements
An itemised Task Schedule, with provisional man day estimates covering each area of activity
A Project Plan with dates and dependencies of the key deliverables required to meet your target Go-Live date
Sign-off from you on all of these deliverables
Further Requirements Scoping Additional tickets to cover further requirements in detail, with proposed solutions and man hour estimates of the additional work involved
Sign-off on the proposed solution and time estimate for each of these tickets
An updated Project Plan, with revised time estimates based on any additional requirements captured
Build Phases Deliverables
Build An OrderFlow instance, configured by us to meet agreed requirements, running in our laboratory environment
An Offsite Handover, during which we do an end to end run through of every operational process
A Test Plan, provided by us, to aid you in further testing the work we have delivered
Sign-off on all processes, integrations and paperwork in scope for launch
Testing Verification of behaviour in live environments using Targeted Live Testing
Verification of Printed Courier Labels with carrier
Instructions on how to complete Labelling of your warehouse
An Onsite Handover of the OrderFlow Build Instance to your environment
Sign-off on completion of testing using the Test Plan and against launch requirements
Preparing for Launch A Dry Run of the data migration from your existing system
A Go-Live Launch Plan, covering the timing and mechanics of migrating of from your existing system
Sign off on the Launch Plan, with an agreed actual Go-live Date and onsite presence
Launch Phases Deliverables
Go-Live A smooth and orderly transition with no disruption to your operations
A live OrderFlow instance, despatching orders
A very happy customer
After Go-live Resolution of all remaining launch issues
Sign-off on completion of launch phase
Post Launch Phases Deliverables
Post Launch An SOP document
A test OrderFlow instance(s)
A positive, ongoing, working relationship
A business running more efficiently and effectively

During the project, we will make up to three on-site visits - depending on your needs - to scope detailed requirements or provide supervision during testing and user training. We will always make an on-site visit for the Go-Live phase.

Project Setup

An OrderFlow implementation begins with a set of setup actions to kick off the project.

Project Setup

OrderFlow implementation project setup involves the following:

  • Identification of key Project Roles
  • Setup on the OrderFlow Support Portal Projects
  • Agreement from you on the Change Control Process and Rules of Engagement for chargeable work
  • Agree timing of Project Kick-off and Weekly Calls

See the sections that follow for more detail on each of these tasks.

Role Identification

At Realtime Despatch, we believe that good communication and clarity of roles and responsibilities is essential for a smooth OrderFlow implementation. Before project setup, it is important to know the names and contact details of the everyone who will be working on the project.

Your Organisation

Role Responsibilities
Project Owner A key stakeholder, who can make strategic decisions and approve large pieces of work.
Project Manager Responsible for maintaining the project plan, and coordinating the activities across all parties involved.
Requirements Lead Understands, in detail, your warehouse design and processes, and so can work with us to define requirements.
OrderFlow Test Lead Works with us to test the OrderFlow implementation in detail before Go-Live. Able to provided detailed feedback to support verification and sign-off.

Note that in some projects, some or all of these roles may be performed by one person.

Realtime Despatch

Role Responsibilities
Realtime Despatch Project Lead Your main point of contact at Realtime Despatch, who will coordinate Realtime Despatch's involvement in the project.
Requirements Lead Works with you to produce detailed specifications for each of your implementation requirements.
Testing Support Lead Responsible for the timely resolution of any issues you might experience during the testing phase.

As with your organisation, some of these roles may be performed by the same person, depending on the project.

Third Party Systems

Role Responsibilities
Support Contact Our main point of contact that we can liaise with when dealing with support issues.

Third party organisations that we tend to deal with include eCommerce and Server Hosting companies.

Redmine Project Setup

All of our customers use our Redmine Support Portal as a wiki and ticketing system to define new OrderFlow requirements and raise any support issues. This single point of contact makes it easier for us and our customers to monitor the progress of specific tickets, and to get an overall picture of how a project is progressing.

During pre-launch phase of project where the emphasis is on rapid and frequent turnaround, we are also happy to use other communication channels to facilitate this.

At the Project Setup stage, we need to know the names of who in your organisation will be raising, updating, approving or simply viewing tickets, so that we can create the relevant user accounts. We will create one user account per person - the same user account should not be used for multiple members of staff.

Typically we will set up one parent project for your organisation, with 3 sub-projects:

  • Launch - during the Project Scoping and Build stages this will be used to define, implement and monitor testing of detailed requirements. Applies only for work that is identified with the scope of the launch project.
  • Support - this covers any work that is identified as being outside the agreed launch scope. After Go-Live this will be used by you to raise support tickets.
  • Development - any custom development work that is commissioned to meet your requirements will be managed through this project.
  • Third Party System - in cases where we are required to have a non-standard integration with a third party system, a sub-project is set up so that we can liaise directly with the technical support staff of that organisation.

In the Change Control section in the next chapter, we describe in more detail the need for separating the launch tickets into a separate launch project.

Project Kickoff and Weekly Calls

Once all key project roles have been filled, and a target launch date has been identified, we're ready to kick the project into gear. This involves:

  • an initial kick-off call or meeting where the participants in the project get together to agree at a high level on responsibilities and objectives for the project
  • a weekly progress call to review progress over the previous week, and agree to agree on actions for the coming week of activity

The weekly progress call is important in ensuring that we are able to maintain momentum throughout the entire period leading up to go live, and that obstacles to launch can be quickly identified and removed.

In both cases, the Realtime Despatch Project Lead will take you through the process.

Change Control and Ticket Management

We appreciate that in real world projects requirements do change, even requirements that were previously considered to be fixed or locked down. We realise the need to maintain flexibility, but also to have a clear mechanism for identifying this work as separate from the work agreed as in scope for launch when the Project Plan is signed off.

As mentioned in Redmine Project Setup, with each new customer implementation we set up two 'projects' on our support portal:

Project Type Covers
Launch All work that is explicitly agreed up front as being delivered on the basis of a relatively firm estimate
Support Work based on unknown, unclear or modified requirements

Where this happens, the work involved will be covered using tickets in the Support ticket, and will be separately chargeable. It will not be offset against any fixed cost allowance made during the Project Scoping phase.

Similarly, work for requirements that cannot be accurately determined during the Project Scoping phase will also be tracked using Support tickets. For example, if courier selection rules are complex, fluid or not well understood, this part of the project will be tracked using Support tickets.

In summary:

  • The Project Plan will not be presented until all Launch Project tickets have been been estimated based on a signed off requirement.
  • No new tickets will be added to the Launch Project after the Project Plan is signed off.
  • All requirements that are added or modified after Project Plan sign off will be tracked using launch tickets.

The project planning we have put in place aims to provide the flexibility the customer needs to make changes where necessary, while ensuring the that risks and costs are associated with these are balanced fairly between Realtime Despatch and the customer.

Agreeing Rules of Engagemeny

As mentioned above, any work that is identifed that is outside of the agreed scope of the launch will need to be separately chargeable. The Rules of Engagement covers details on which situations charges are applied, how we seek approval for work, and how we book time.

Please refer to our Customer Support Guide for details of our default rules of engagement. This document will also tell you more about our technical support and development processes.

As suggested, an important area that this document covers is in the area of Billing and Time Booking.

We request explicit agreement from you that you are comfortable with these rules of engagement before we proceed the implementation of the project. If there is anything in the document that you do not understand, or if you wish certain exceptions to be made for your specific implementation, then please discuss this with our Project Lead.

Project Timeline

Customer Sign-off Notes

Getting the mechanics of the project setup, with Support Portal interaction through tickets and weekly calls,

is essential for efficient communication and smooth running of the project. Agreeing the Change Control and Rules of Engagement gives us a commercial basis for handling unplanned or unanticipated work while not limiting your flexibility in making changes.

Project Scoping

The main aim of the Project Scoping phase is to gain a much better understanding of the likely effort required and anticipated cost of the project. The Project Scoping phase provides is a key sign off point in the project, and is where the overall scope of the launch is largely determined.

Project Planning

In the proposal you received as part of the sale, the Realtime Despatch sales professional would have given you a pretty good idea of what is involved with the project, and the likely implementation cost. With the Project Plan, the aim as to firm this up.

This involves an initial round of Requirements Gathering, done through the initial visit to the customer site. This will be followed by an estimation of the Tasks involved in delivering the project, both of which will feed into a Project Plan and a more accurate estimate of the project implementation costs.

Deliverables
"A Requirements Document, with an itemised summary of your requirements"
"An itemised Task Estimation, with man day estimates covering each area of activity"
"A Project Plan with dates and dependencies of the key deliverables required to meet your target Go-Live date"
"Sign-off from you on all of these deliverables"

Requirements Gathering

We encourage new customers to lean towards the simplest, most standard implementation for launch. This allows for the fastest, lowest cost implementation. Refinements can be introduced once the system is operational and the benefits are better understood and more easily quantifiable. This allows for a faster, lower risk implementation.

A simple generic implementation would typically involve the following features:

Areas to Consider Example Basic Configuration
Locations Basic warehouse location configuration, involving, incoming, storage, and outgoing locations, mobile locations
Products Simple products only, all individually barcoded
eCommerce Integration Integration to a single eCommerce platform
Courier Integration What are the despatch destination countries? Which couriers and services are needed for each
Goods-in Standard goods in to incoming location, followed by putaway to storage
Picking Handheld picking to single mobile location
Batching Simple batching logic, involving single and multilines, batched by priority and domestic vs international
Packing Standard scan to pack process
Returns Simple returns process using desktop GUI, with no third party system integration
Handhelds Out of the box handheld usage, no custom styling
Paperwork Use of standard out of the box paperwork, with text and logo customisation only
Printing Use of industry standard thermal printers. Workstations running on Microsoft Windows
Reporting Use of standard reports only
User Roles Mapping of users to predefined roles only

Inevitably, however, there will be some bespoke requirements that will be considered essential for launch. Part of the task of the Project Scoping phase will be to identify these requirements, and to ensure that they are recorded as in scope for launch.

The task of identifying as early as possible and as fully as possible bespoke requirements is very important in allowing us to accurately to estimate the overall effort. This helps to establish a sound commercial basis for the project, and to ensure that there are no unanticipated cost overruns.

The table below shows the key areas where requirements or input will need to be captured:

Areas to Consider Example
Locations How are locations labelled and named? How is the warehouse organised. A list locations will need to be provided.
Labelling What label stock will be used for product and location labels? What label reports need to be supported?
Products Do all products have barcodes? Any complex/composite products
eCommerce Integration Which platform/integration to use
Courier Integration What are the despatch destination countries? Which couriers and services are needed for each
Paperwork What are the depsatch documentation requirements? Do we have any examples?
Handhelds Which handheld terminal does the application need to run on?
Printing Which thermal printer needs to be used?

The output of requirements gathering step will be a Requirements Document, with the following:

  • a summary of the customer requirement in each area of activity
  • a link to associated detailed tickets, where appropriate
  • an indication for each associated ticket on whether the detailed requirement has been signed off

The Requirements Document will be prepared in a standard format. It will be reviewed internally before being presented to the customer for sign off.

Task Estimation

Once we have completed the first round of requirements gathering, the next step is to estimate the tasks involved. For this the man day effort required for each area of activity for which project delivery is required.

In an ideal world, it would be possible to arrive at a firm set of detailed project requirements before continuing to the build stage of the project.

In practice, it is not always possible to obtain project requirements that are sufficiently detailed to allow this to happen. Typically, decisions still need to be taken, and these decisions can affect the scope of work involved.

Where scope of work can be clearly defined, we would give you the option of having this work done on a fixed price prices basis. Where this is not possible, at the Project Scoping stage we would aim to give you a provisional cost estimate for each activity.

The differences between these estimate types are described below:

Estimate Type Covers Situations Action
Fixed Price Requirements are well defined at the Project Scoping stage Realtime Despatch provides a fixed price estimate and absorbs the cost of overruns in this area
Provisionaly Allowance Requirements are still to be defined Realtime Despatch makes a provisional allowance for the activity

The output of the task estimation process will be a Task Estimation Document, prepared in a standard format, with the following information:

  • an itemised estimate for preparing the system to meet the requirements
  • an itemised estimate for delivering each of the remaining phases of the project

For each estimated item, we will indicate whether the estimate is on a fixed cost basis or whether it is provisional.

The Task Estimation will be reviewed internally before being presented to the customer for sign off.

Project Plan

The requirements and estimated tasks will feed into an overall Project Plan which will summarise timings and cost estimates for the project:

  • the target go live date for the project
  • the proposed timing of the remaining phases of the project
  • a proposal for the timing and number of days for which we will be on site to deliver the project

The target go live date will take into account customer business imperatives, but also resource availability on the part of both Realtime Despatch and OrderFlow.

Note that actual go live date will need to be confirmed later in the project once the build and testing phases have been signed off. Requirements that are identified or changes that are made after the sign off of the Project Plan will typically have an impact on the go live date that is actually possible.

Project Team

Customer Sign-off Notes

Customer sign-off on the Requirement Document, Task Estimation and Project Plan is essential before continuing to the build phases of the project. It is this process that identifies the scope of the project as a whole. The more clearly and accurately requirements can be captured and 'locked down' at this stage, the more certainty we will be able to provide as to the total cost of implementing the project.

Further Requirements Scoping

Further Requirements Scoping covers requirements that still need to be scoped in order for the system to be built, but are not fully covered during project planning.

Project Further Requirements

As we define your requirements, we will raise tickets in your Support Project if necessary.

Note that the start of the Build Phase of the project does not need to wait until all of the additional requirements have been identified and signed off. However, it will not be possible to complete the Build Phase and move on to launch while there are still outstanding tickets with further requirements outstanding.

Deliverables
Additional solution tickets to cover describing your requirements in detail, with proposed solutions and man hour estimates of the work involved
Sign-off on the proposed solution and time estimate for each of these tickets

Build

The Build phase is where the main body of work gets done to prepare the system for launch based on the signed off requirements.

Project Build

The Build phase itself involves a sign off process, which involves the customer confirming that the system has been set up in a way that meets all of the requirements for launch. Other outputs of the build phase include a Test Plan, which is a fairly basic document with instructions to the customer on what should be covered in their testing, both before launch, but also prior to future upgrades.

Deliverables
An OrderFlow instance, configured by us to meet agreed requirements, running in our laboratory environment
An Offsite Handover, during which we do an end to end run through of every operational process
Sign-off on all processes, integrations and paperwork in scope for launch

During the Build phase, we will contact you when required for further input on individual pieces of work, and also keep you informed of progress during the weekly project call. However, there will be no formal handover of work while the build phase is in progress.

Almost all of the time spent during the the Build phase will be off site. It will not be physically delivered into the customer environment after a formal handover and sign-off process.

OrderFlow Build Instance

The key deliverable in this stage is an instance of OrderFlow that can be verified as meeting requirements for launch.

The table below makes it clear what the Build Instance would entail.

System Area Typical Salient Features
eCommerce Integration End to end integration with your test eCommerce platform
Courier Integration Integration with the test intance/account for all of your couriers
Locations Your actual warehouse locations, some of which will be physically represented in our lab environment
Products The product catalogue obtained from your eCommerce system
Courier Selection Rules applied according to launch requirements
Picking Batch Selection Rules applied according to launch requirements
Handhelds Verification using one of the actual handheld scanner
Paperwork Despatch notes, product, location and user labels as required for launch, using customer's label stock
Workstations Complete setup of a single packing workstation using actual thermal and/or A4 laser printer
Printing Verified printing of all paperwork using customer's thermal printer (or identical copy)
User Roles System set up with launch users, appropriately restricted by role

In addition,the Build Instance will be configured so that all warehouse processes, including Goods In, Putaway, Picking, Packing, Despatch and Returns are configured as per signed off requirements in the manner intended for launch.

Offsite Handover

Once we are confident that OrderFlow Build Instance is suitably configured to meet all signed off requirements, we will arrange for an Offsite Handover.

The Offsite Handover take places in our laboratory environment, and involves just the key customer staff members involved in the project. During the handover, we do a walkthrough of all of the integrations, processes, and outputs.

Typical tasks that would be covered during the Offsite Handover:

System Area Typical Tasks
eCommerce Integration Verify import of products into OrderFlow from test eCommerce instance, verifying field level detail of data received
Verify import of orders into OrderFlow
Courier Integration Verify integration with each courier (using test account), with successful validation and label generation for each service
Verify integration for all services handling international shipments
Verify end to end flow of address information for each interaction
Verify physical printing of label for each supported service
Courier Selection Verify the courier selection rules used to select each service, against stated requirements
Picking Batch Selection Verify the courier selection rules used to select each service, against stated requirements
Goods In and Putaway End to end verification of receipt and putaway process, with appropriately role restricted users, and use of handheld where appropriate
Picking and Packing End to end verification of picking and packing process, with appropriately role restricted users, and use of handheld where appropriate
Printing Verify the physical printing and contents of despatch notes, for each test shipment packed
If not using handheld terminals
Verify examples of location, product and user labels to be used for launch
Despatch Verify any manifesting and despatch process using imported shipments
Labelling Verify that aspects of labelling in preparation for onsite handover day

As preparation for the day itself, we will create a Test Plan. This is a simple document describing at a high level the tests that will be carried out during the Offsite Handover.

In each area, the outcome of the handover/verification will be recorded against the signed off requirements. Any outstanding issues raised against existing requirements will be noted and resolved as part of a follow up.

Additionally, if new or changed requirements are identified at this point, new tickets will be raised in the customer's 'Support' project, as per the Change Control process. For each of these, a decision will be taken on whether the new requirement should be brought into scope for launch, with the obvious consideration of the potential affect on the launch date.

Why an Offsite Handover?

Customers may be asking why the main formal handover against requirements is done through an offsite day. In order to make most efficient use of everyone's time, it is critically important to have the customer's full attention during the requirements gathering and verification process.

In practice, we tend to find that can be quite difficult at the customer site; without the pressure of an imminent launch, it is very easy to become distracted by more immediate problems.

With an offsite day, you get opportunity focus fully on the OrderFlow implementation project, allowing for much more rapid progress in preparing for launch.

Allow a full day for the Offsite Handover, with an early morning start!

Handover of further pieces of work required for signing off the OrderFlow Build Instance will be done incrementally in the days following the Offsite Handover.

Customer Sign-off Notes

Customer sign-off on the OrderFlow Build Instance will need to take place before it can be delivered to the customer environment, which takes place during the testing phase, described next.

Testing

With the Build Phase complete we are confident that OrderFlow is functionally ready and configured to meet launch requirements. The purpose of the Testing phase is to get to the same level of confidence with the OrderFlow set up for the customer's warehouse.

Project Testing

The main deliverable is an Onsite Handover, with the plan to have a fully operational warehouse environment that uses the OrderFlow Build Instance. However, before we get to this, the Testing phase needs to incorporate some targeted live testing, and ensure that labelling requirements have been met.

Deliverables
Verification of behaviour in live environments using Targeted Live Testing
Verification of Printed Courier Labels with carrier
Instructions on how to complete Labelling of your warehouse
An Onsite Handover of the OrderFlow Build Instance to your environment
A Test Plan, provided by us, to aid you in further testing the work we have delivered
Sign-off on completion of testing using the Test Plan and against launch requirements

Targeted Live Testing

The Build Phase would have involved full verification in the Lab environemnt of all functionality against test environments.

It is not safe to assume that just because everything works in test, it will all work in live. In order to derisk the transitions to live, some Targeted Live Testing should take place.

Targeted Live testing involves the following:

  1. all schedules are disabled, so that there are no unplanned notifications back to live system reporting false stock positions or order statuses.
  2. a full catalogue pull of the products from the live eCommerce system, followed by a comparison of the products data with that retrieved from the test system.
  3. a pull of specific orders from the live system. These should be orders that have been specifically created for testing, to 'friendly' addresses.
  4. courier interaction on the live account, for every destination group (combination of countries) and service. Arrangements should be made beforehand with the carriers.
  5. the parcels should be physically sent, to ensure that they pass through the courier system without any issue.
  6. shipment notifications to the eCommerce system should occur for each of the sent orders.
  7. targeted individual stock notifications should be sent to verify this interaction, with the stock position adjusted beforehand to coincide with the current actual live position.

Once the Targeted Targeted Live has been completed, the OrderFlow Build Instance should be switched back to use test credentials.

Courier Delivery

Labelling Instructions

During the Onsite Handover, we will want to ensure that all of the labelling requirements have been met. All of the location, workstation, product and user labels must be prepared prior to the Onsite Handover.

To get to this point, there will need to be a further interaction. At the end of the Build Phase we have verified the examples of each of the labels that need to produced.

We will also have confirmed that we have a common understanding on the location labelling scheme to be used, and how locations need to be inputted in the location spreadsheet.

The following then needs to happen:

  1. You the customer will provide an updated list of the locations on the system, which we will double check
  2. We will provide precise instructions for printing the location, product and user labels required
  3. You the customer will print location labels, and label up all of the warehouse labels appropriately
  4. You will print user labels as required

During the Onsite Handover, the labelling will be verified.

Why label beforehand?

You may be asking why we don't just defer the labelling to the Onsite Handover.

The labelling task is quite a relatively straightforward but time consuming exercise. If the warehouse is labelled in time for the Onsite Handover, many of the operations that we need to hand over on the day will not be possible.

If you would like us to schedule an extra site visit to support you through the labelling task, please let us know, although please bear in mind that this will entail an additional charge.

Otherwise, we will check with you to ensure that labelling has taken place before doing the Onsite Handover, and if necessary defer the site visit until this has taken place.

Labelling

Test Plan

The Test Plan used for the Offsite Handover serves an additional function as a useful document for allowing the customer to perform further testing of their own, both prior to launch and afterwards. Before the Onsite Handover takes place, we will make this document available to customer to support your testing efforts.

Onsite Handover

Environment Verification

One of the first tasks as part of the environment handover is to verify that the physical environment is suitable. Some of the checks that we will apply include:

  • check that locations have been labelled as agreed
  • check that products are barcoded as expected
  • check that the handheld terminals work within the warehouse (and that the Wi-Fi signal works in all parts of the warehouse)
  • verify that there are no network connectivity issues between the warehouse and OrderFlow

Transferring the OrderFlow Build Instance

The idea is to arrive at the Onsite Handover not empty handed, but ready to put in place a system that works straight away.

Specifically, we arrive with the following:

Inputs Source
OrderFlow Build Instance This has already been signed off at the end of the Build Phase
Handheld Terminal Borrowed from the customer for the Build phase
Thermal Printer Borrowed from the customer for the Build phase
Workstation Sourced by Realtime Despatch for the Build phase
Label Stock Typically sourced from the customer prior to the build phase

All of the items listed above will have been configured and tested in the Lab environment, and verified during the Offsite Handover day. This means that as soon as everything has been plugged in, we will already have:

  • a working handheld device, that has been tested against all of the processes
  • an instance of the Print Server, installed on a workstation, pointing to OrderFlow instance
  • a thermal printer configured and connected to the workstation

Replicating Configurations

Once we have OrderFlow running in the warehouse with one handheld terminal and packing station, the next step is to replicate these configurations so that they can be applied across multiple packing stations, handheld devices and printers.

We will provide your IT Support person with instructions on replicating these configurations. Crucially, they will have a working example of each item to consider as a reference point.

User Training

Unlike Offsite Handover, which we would have been leading, you will be very much in the driving seat during the Onsite Handover.

The aim is to help primary customer users to gain confidence in their use of the system. This as an opportunity to do further training, answer questions, explain concepts, and generally share knowledge on the use of the system.

During this period, we will be guide you through the Test Plan. After our departure, you will then be able to continue to test the processes, building your confidence in the system, and making sure that you are ready when the launch date arises.

We take a 'train the trainer' approach to user training, so the knowledge that you build during the Onsite Handover will be key in ensuring that all operators who need to use the system can be trained.

Handheld Terminal

Courier Sign-off

The testing process should include courier sign-off where appropriate. The exact details of what this involves should be checked with the courier account managers. A reasonable requirement may be to print labels for shipments for each courier service and destination (country or country group) combination, and to send these to the carrier for verification.

Testing Sign-off

The final step in the Testing phase of the project is the Sign-off on testing. We will ask for formal sign-off that on the following:

  • that Targeted Live Testing has been successfully completed
  • that all testing has been completed according to the Test Plan and against Signed-off requirements
  • that there are no further additional requirements that should still be considered in scope for launch

Congratulations for getting this far - we are now ready to prepare for the actual go live!

Customer Sign-off Notes

We will not be able to agree to an actual go live date until formal sign off of testing is complete. Up until then, may have a date in mind which we will have been working towards. However, commitment to supporting a specific go live date will not be possible until customer testing as been signed off.

Preparing for Launch

With the system functionally complete and the warehouse fully ready, we're now ready to plan for and verify the mechanics of the launch itself.

Up until now we may have had a target launch date in mind. For the first time, we will be able to propose an actual launch date that we can commit to.

Project Prep for Launch

The key deliverable for this phase involves us preparing a tailored Go-Live Launch Plan, which we can use to plan the precise timings around launch, and use during the Go-Live phase to ensure that everything we need to do is completed. However, we also want to dry run the data migration, and ensure that the launch plan is fully signed off before the Go-Live day arrives.

Deliverables
A Go-Live Launch Plan, covering the timing and mechanics of migrating of from your existing system
A Dry Run of the data migration from your existing system
Sign off on the Launch Plan, with an agreed actual Go-live Date and onsite presence

Dry Run of Data Migration

There are two objectives we are looking to satisfy when doing the dry run:

  • we are able to easily and accurately transfer the stock position from the old position into OrderFlow, without having to do a full stock check.
  • we are able to ensure that status of pending orders can be accurately captured to ensure that no order goes through both the old system and OrderFlow, and that no order is 'lost' during the migration.

In both cases, we will be relying on relevant reports and/or control mechanisms being present in the e-Commerce system. The dry run will be to ensure that these can effectively be applied on the day itself.

Go-Live Plan

The detail of this plan will depend on whether you wish the instance of OrderFlow you have been testing to become your live instance, or we need to create a completely new one.

The Go-Live Plan launch plan will cover:

  • All the implementation steps - extracted from our Redmine implementation tickets - required to configure your live instance of OrderFlow.
  • Confirmation of the steps that need to be taken to migrate data from your current Warehouse Management System (WMS) onto OrderFlow, already verified during the Dry Run.
  • The timing of out on site presence to support the launch.
  • The timing of individual steps in the launch sequence.

Once prepared, the Go-Live Plan will be internally reviewed, before being signed off by the customer. We will only present the Go-Live Plan for sign-off from the customer once the dry run of the data migration has been verified.

Sign-off Notes

During the Go-live it is critical that the customer sticks to all elements of the agreed launch sequence. For this reason, we will request formal sign-off on the Go-live Plan.

Note that our scope for making changes will be limited after this point. If unanticipated changes do need to be made during the Go-Live, please be aware that are likely to be cost implications and a potential delay to the actual launch date.

Go-Live

The Go-Live phase covers the key moment that we've all been waiting for, when you stop using the old system and start using OrderFlow.

Project Go Live

Before, during and after the Go-Live date, someone from Realtime Despatch will be on-site, with you, to ensure that everything goes as planned. We will work quickly and efficiently with you to resolve any issues that arise, and will stay on-site until you are comfortable that your operations are running smoothly.

Deliverables
A smooth and orderly transition with no disruption to your operations
A live OrderFlow instance
A very happy customer

In the next section, we describe the timeline of a typical launch sequence.

Typical Launch Timeline

Days of Week All

We plan a launch migration around the working week. The idea is that you have a little bit of time at the start of week to limit the likely backlog, but have enough time to get the migration done during the week without having to go into the next weekend.

Monday

Before the launch we need to ensure that the live configuration has been correct, and get OrderFlow ready by pulling in all of the live products onto the system. At this point you're still using your old system, working particularly hard to make sure that there as a few pending orders as possible on the old system when the migration takes place.

Days of Week Monday

  1. In the morning we clear down all transactional data, including orders and products, from OrderFlow.
  2. We ensure that OrderFlow is pointing to the live URLs for the eCommerce and courier systems, by replaying the setup used for Targeted Live Testing. Note that automated (schedule-based) operations will be turned off at this point.
  3. You verify that all of the packing stations are configured correctly.
  4. We trigger a full catalogue pull, so that all of the live products are present on OrderFlow.

At this point, OrderFlow is standing by with a full product catalogue, but no orders or stock on the system.

Tuesday

On this day the old system is decommissioned. The stock on OrderFlow is synced from the old system, before the latter is switched off.

Days of Week Tuesday

  1. The OrderFlow Support Engineer arrives at your warehouse premises at 4pm on Tuesday.
  2. The Support Engineer confirms with you that you have stopped taking new orders onto you old system, and reviews with you the launch steps.
  3. You the customer stop processing orders or making stock changes on your old system. This must take place on the day prior to launch.
  4. You export a list of pending orders that are in the old system but have not been processed.
  5. You also ensure that all shipments that have been processed in the old system are closed off on the e-Commerce system, so that they are not pulled into OrderFlow.
  6. You export the stock position for all products and locations in the old system.
  7. You disable the old system, so that no further order or stock changes can be made there.
  8. We import the stock position into OrderFlow.

At this point, OrderFlow is ready to go for order processing. It hasn't received any orders, but its product catalogue has been synced and its stock position is accurate.

Wednesday

This is the Go-live Day, with all order processing done on OrderFlow. Order processing starts first thing on Wednesday morning.

Days of Week Wednesday

  1. A few selected orders will be pulled onto OrderFlow, and pushed through the system end to end to ensure that all of the key pack and despatch processes are set up correctly.
  2. When previous step has been successfully completed, unprocessed orders will be pulled into OrderFlow.
  3. The OrderFlow Support Engineer continues to work with your operational staff to deal with any issues that may arise, but otherwise to support general user training.
  4. A second OrderFlow Support Engineer will be on standby to deal with any more significant issues.
  5. Together we ensure that all processes are working end to end, including despatch and stock notifications to the shopping carts, and any other 'end of day' processes.

During this day you would have processed a substantial number of orders, but a backlog may have developed during the transition. Over the next few days, this will be worked off.

Thursday

While the primary focus on the previous day will have been on order processing, as long as all goes well it will be possible to shift some of the focus to other processes. In exceptional cases, a second Onsite Support day may not be necessary, and a call as to whether this is required can be made on Wednesday evening. However, you should certainly allow for this in the project planning.

Days of Week Thursday

Friday

This is the 'emergency' extra day, which should only be needed if some unexpected issues arise which cause a delay in progress.

Days of Week Friday

Verification of Launch Requirements

Throughout the Go-Live period, the OrderFlow Support Engineer will be cross checking the system behaviour against launch requirements, and where possible, asking you the customer for verification that the system is behaving as expected. Where not, depending on the situation the issue will either be fixed as a matter of priority (possibly with the help of the offsite Support Engineer) or scheduled for resolution during the After Go-live phase.

Unanticipated Further Requirements

Situations may also arise where further changes are required to resolve problems in ways that were not anticipated during the Requirements Gathering or Build phases. While outside the official scope of the launch, these changes may be operationally very important, and as such will be treated with the appropriate level of urgency, and if necessary even addressed during the Go-Live period.

Note that work done to address unantipated changes of this kind will be chargeable outside of the budget of the project, unless it can be resolved in situ by the onsite OrderFlow Support Engineer.

After Go-live

By the time the OrderFlow Support Engineer leaves your premises at the end of the Go-Live phase, you will be confidently processing orders, handling stock, and dealing with any on the ground situations that arise. There will need to be a little bit of 'tidying up' before the launch is complete. This takes place during the After Go-live phase.

Project After Go Live

The main main deliverable here is formal completion of the launch phase, which itself will require all remaining launch issues to be resolved.

Deliverables
Resolution of all remaining launch issues
Sign-off on completion of launch phase

Helping

Resolution of Launch Issues

Here we undertake work to resolve any launch issues that were not closed off during Launch Issue Resolution. This will be done via ticket interactions on the Support Portal.

Formal completion of the launch should not take place until all of the Launch Issues have been resolved. In practical terms, this means that all of the issues in the 'Launch' project on the Support Portal will have been closed off.

Data Retention and Removal

During the Project Scoping phase, we would have covered your requirements regarding Data Retention and Removal. This is both to ensure that we are compliant with any Data Protection regulation and best practice, but also to ensure that data does not accumulate on the system in a way that will harm performance or result in excessively long upgrades.

During the immediate post-launch period, we will put these policies into effect.

For more information, please see the Data Retention and Removal Policy.

Addressing Non-launch Issues

As mentioned in the previous section, further non-launch issues may have been identified as Unanticipated Further Requirements. High priority issues in this category, that is, issues are having a significant operational impact, will also be addressed at this point.

Lower priority issues, or issues involving more substantial effort, will not be addressed until after the launch is formally completed.

Customer Sign-off Notes

We like to end the project launch phase with a formal sign-off that launch is complete. This involves an acknowledgement from you the customer that the system meets all of the requirements that are within the scope of the project's launch.

There may be plenty still to do to get the system exactly working the way that you want, but this activity can begin as part of the post-launch effort.

Any significant post-launch activity, including custom feature development or new projects, can be initiated once the completion of the launch has been signed off.

Post-Launch

Even heartier congratulations if you've gotten to this point! You are now officially live with OrderFlow. Of course, this may be just the end of the beginning. We will have encouraged you to keep your launch simple, but now that you are live, you may have a shopping list of things you would still like to change on the system. Now is the time to put these into practice.

projectPostLaunch

Apart of a Standard Operating Procedures (SOP) which can be helpful, the main deliverable here is a program of initiatives, based on effective mutual cooperation and long term partnership, to get OrderFlow working exactly how you need it to deliver maximum business value.

Of course, if you are happy the way OrderFlow works for you from day one, that's great too; we'll be happy to support you through whatever needs you do have going forward.

Deliverables
An SOP document
Your test OrderFlow instance(s)
A positive, ongoing, working relationship
A business running more efficiently and effectively

SOP Document

We recommend that you create a Standard Operating Procedures (SOP) document. We don't create this document as part of the project implementation, as we believe a good SOP document will embed a lot of information that is very specific to you and the people in your business, and not just the mechanics of the processes you are running. The Test Plan may be a suitable starting point for this document.

We can of course support you in the creation of this document in whatever way you see fit.

Test Instance Creation

At this stage, we will also be involved in setting up OrderFlow test environments for you, so that you can test any future bug fixes, bespoke developments or upgrades provided by us. Every customer will need to have at least one test environment. For larger, more complex environments, we recommend that you also consider a staging environment, which allows you to use the test environment for verifying more experimental changes, and the staging environment for testing upgrades.

Typically, a test instance is created by taking a copy of your live instance, then taking steps to ensure that any links to live data or systems are changed.

We will require that a test environment be commissioned (and used!) before any upgrades are applied.

Post-Launch Support

Post-launch support is covered in detail in our Customer Support Guide, however here is a summary of the key points you need to be considering as early as possible in the project:

  • For OrderFlow support, you will be using our Redmine Support System to raise support or development request tickets. Please note that only nominated users should raise tickets as we do not provide first line support to end users.
  • For issues with eCommerce or Courier systems, in the first instance it is more cost-effective for you to contact the relevant System Helpdesk. Of course, we are happy to assist in this process by providing log files or other information that might be helpful.
  • IT Infrastructure and Server support will be the responsibility of the organisation you have chosen to provide these services. If we are hosting your OrderFlow instance, then of course we will handle any issues related to the host server. However we do not provide support for any other IT issues such as network or printer problems.

Technical User Training

Some of our customers benefit from the technical user training that we offer for the more IT-literate OrderFlow users in their organisation. This could help you get the most out of OrderFlow, and may also be more cost-effective for you, in terms of support costs.

Ongoing Enhancements

We see a successful launch as just the beginning of our relationship with you. Although we aim to keep our launches simple to minimise the risk, training overhead and complexity of the implementation, we fully anticipate that you will have further requirements in the future, as you get used to OrderFlow and have a better understanding of its capabilities. The process for raising change requests is covered in our Customer Support Guide.

We will encourage you to periodically upgrade to take advantage of new OrderFlow features and, where geographical constraints allow, will visit with you at least once a year - more frequently if you prefer - to ensure you are getting the most from OrderFlow, and to make you aware of any new features that may be of use to you.

Further Reading

Please refer to our Internal Customer Documentation Page for more detailed OrderFlow documentation.