Case Studies - What We Can Do
1. Automating A Manual Workflow
The Problem Statement
All companies have processes that are completely manual. This case study is about
automating a large manual process and doing it right. The original process averaged
60 days from receiving a request until the equipment was installed at the customer
site. After implementing our system, the process took 4 days. 3 days of both
the manual and automated process was the shipping and installation of equipment.
The original process allowed sales representatives to declare a product was a "lemon"
and ask for replacement equipment to be shipped and installed. The sales rep would
download and print a multipage form, fill it in, and mail it to an office. The form
had to have places for all the possible questions the people processing the request
might ask for any covered product. The products varied from small, simple products to
ones that took up half a room and required major configuration.
The receiving office created a folder for the request, validated the sales rep
information, the customer information, pulled the original order from a back end
system and printed it, pulled the service history from a different back end system
and printed it, put all this in the folder, then mailed it across the country to
one of a very few people who could approve the request.
The approver would look at the documentation, consult the company policies (which
differed by product), possibly consult with the sales rep, and then either approve
or deny the request. Occasionally, the request was not for an exact replacement (a
Like-for-like), but for an upgraded product or a completely different product. Sometimes
only an accessory for a large product was requested. These generally required different
approvals.
When a request was approved, the folder was mailed to a group that made a search
for equipment that might be used to satisfy the customer. Reconditioned equipment
near the customer was the preferred option. Other options were reconditioned
equipment not near the customer, returned equipment that was not yet reconditioned,
and new equipment. All these had costs for possible conditioning, shipping, and
installing.
When the equipment was identified and reserved, a group would handle
the conditioning if required, then another would prepare the equipment for shipping,
and finally yet another would actually ship it. A technician would be dispatched to do any
installs. Finally, it went through a couple of finance steps to account for the movement
of an internal asset to a customer and to charge sales and customer support for the
cost of the activities.
All these activities would add paperwork to the folder and then mail it to the next group.
Sometimes they did not choose the right next group and the folder had to be mailed again.
Occasionally, the folder would be lost in the mails. To protect against this, copies of all
the folder were made over and over and stored for long periods of time.
The Solution
We started with a web site that was available 7x24. The sales rep used his normal
network credentials to access the site. The site walked the rep through the data
entry required, but only asked for data that was appropriate for the equipment and
type of request. It validated the serial number information, the customer information,
and other items that would prevent processing.
Where possible, it would provide a
list of choices rather than let the rep enter free form text. This eased the rep's
task and normalized the input data.
The application also ensured that the accessory
requested was actually installed on the customer's equipment and that it was still in
the company's products list. If not, it determined the replacement accessory. If the
input was stopped at any point, the current data was saved as a suspended transaction and
the agent could complete it at any time.
It was decided the rest of the system was a state-driven work flow system. As Windows
Workflow was not yet invented and BizTalk was in its infancy, we designed a set of
database tables to define the various states of the system and the transitions between
states. The triggers for transitions were sometimes complicated so we provided an exit
on entering a state and on leaving the state where actions could be invoked and a set
of conditional fields.
We also defined a set of groups, employees, roles, equipment, and a request. Employees
could have various roles in relation to a given request and often had more than one.
State transitions were always to a group. When an employee logged into the web site,
a queue of requests that members of that group could help move to another state would
be displayed. Emails were sent to members of a group (when configured) when new work
was added to the group's queue. Pagers could also be activated.
We determined what documents each group used in their work on a request of a particular
type. Mostly they accessed back end systems to display sales records, financial records,
inventory records, service records, etc. In all cases, we accessed those systems as early
in the process as we could and put copies of the records at that point in time in our database.
When an employee selected a request, all the relevant records were offered to them without
using any other system. Since we stored a copy and not a pointer, the records became part of the
audit trail which explained why the request was processed as it was.
We added an audit trail that showed every action either the application or an employee took for a given
request. The employees could add comments to this audit trail also to explain their actions. All
notifications were also put into the audit trail. The audit trail was always displayed (in a
scrollable panel) with the request with the latest entries at the top. This made it easy for
anyone to see the current status and how it got there.
A real problem with the manual system was determining the current status. A sales rep would
attempt to follow up for his/her customer, but could not determine where the folder was waiting
for processing. With the new system, the rep could check the status at any time. In fact, any
employee along the processing path could ask to be notified whenever the status changed on a
request. They would receive an email with the main information, the status change, and a URL
to bring up the full request.
The replacement equipment was ordered and shipped through another system when the request
entered the correct state for that. A background process tracked all the orders and updated
the audit trails and status (and, therefore, state) of the request automatically.
The Results
This totally eliminated all the shipping of documents across the country. It created better
tracking. It created complete audit trails. It interacted with existing systems to get data
and to cause actions in the physical and financial worlds. It prevented errors. As they learned
what the system could do, they streamlined
their processes and we generally only had to change state/transition data in database tables to
handle the changes.
It reduced processing time from 57 days to 1 day!
Needless to say it took unhappy customers and made them
happier. It also did this for a lot less money than the manual system had been costing. In
fact, it saved millions of dollars per year.
And, best of all, the total development time from requirements to delivery was
less than six weeks!