|
Business Accent
Play and Learn with a Sandbox
Ipshita Basu argues that a sandbox is a vital tool
to beef up RoI and cost savings
Ipshita Basu Guha
|
Remember your childhood days when you went to the beach and
played with sand or that clay mold in your playthings which could take various
shapes based on how linearly or laterally you thought. The beauty about them
was that they allowed you to try and test different ideas, make newer shapes
and structures. You did not require fresh sand or clay each time; you could
just dismantle the design and do it differently without causing any harm.
In IT parlance, a sandbox is a system that is properly isolated and secured
so that any changes made in it do not affect the entire set of live system users.
One can test new programs or software or logic in this sandbox client and see
the outcome for analysis. It is similar to quarantining a system. One can test
unverified code and patches before introducing the same into a live environment.
The aim of this article is to verify the utility of sandboxes for non-IT organizations.
A sandbox can also be considered to be synonymous with a prototype or simulated
system of a real-life model. The access rights of this system are severely restricted
and help secure functional systems from crashing or functioning improperly.
The question is what is the motivation for a non-IT company to invest in a sandbox.
The answer is that a sandbox is quite helpful if you have an ERP or client server
application deployed in your organization. Sandboxes come in various configurations.
Investing in one is an important decision for a SMB since cash constraints exist.
Let us look at the pros and cons of this decision and the rationale behind it.
When you introduce any new (complex) application or software from scratch most
of your resources are spent implementing and going live. The general belief
is that once an implementation is over and done with, we can start functioning
peacefully. Right? Wrong! There is something called the learning cycle or curve
which comes into force.
Many users initially oppose a new system. Over time (if the application is really
good and proven) the same users will start using the application and gain confidence
in it. At some point they become fluent in using the application and it becomes
a part of their work life. We have dealt with resistance to change in many articles
but what happens when we overcome these negative forces and obstacles? People
are in sync with the application and start adopting it. So now logically the
learning curve might slowly start taking a downward slope. Unfortunately logic
fails on this occasion and the learning curve starts sloping skyward again for
some of those involved employees. Let us look into the phenomenon of a learning
cycle or curve.
Learning cycle or curve
A learning cycle of any individual or group is similar to a product life cycle.
The development stage commences with the initiation of pre-implementation gap
analysis and introductory training being given to users. General awareness is
created about the product and functionalities are touched upon in this training.
People are slightly confused but eager to learn about the new application including
the skeptics. This introductory stage is marked by the first round hands-on
experience of the end-users on the new application. The entire horizon is ahead
of them. The scope of learning is definitely going up and rising at this juncture
since one has to understand the functionalities of the system presented to them
before forming a positive or negative opinion about the same. As usage increases
day by day and regular functions are used with ease, users phase into the growth
stage. At this stage they are still unsure about the various permutation and
combination of entries but are still able to manage with bits and pieces of
guidance here and there. Finally the users become fluent in regular functions
and are seasoned pros. At this stage they are capable of training and maneuvering
new entrants through the application. Now users are deemed to have attained
the maturity stage. Once the initial novitiate period is over and the application
loses its grandeur and becomes ordinary the interest in the same starts waning.
Most users know about the frequently used functions of the application like
the back of their hand. Once the exclusivity of the application diminishes so
does the urge to learn and there is a decline in interest.
One important factor in relation to the maturity stage is that though the interest
level in the general usage of the application wanes at some point the questioning
human mind takes over. The ability and efficiency of the application is demonstrated
to users and many are propitiated by its powers. What was earlier unthinkable
and unattainable (e.g. year-end books closure in one months time) is now
a reality and all too possible. This prompts many involved users to further
examine the strengths and features of the application. In the meantime the application
vendor also may launch some upgrades and patches with certain enhancements that
ease usage. These reasons fuel a fresh phase of learning curve.
The downside
The most evident downside of investing in a sandbox is cost in the form of man-hours,
machine, software, licenses, hardware etc. The least that you require is a separate
server and its related requirements. As mentioned, sandboxes allow you to test
and simulate certain instances hence considerable man-hours are spent. It depends
on whether the management views it as an investment or cost. Important resources
get tied up during periods of testing and simulation. There is an opportunity
cost for each option. The sandbox clients require regular maintenance just like
the live production clients. These investments are also linked to the overhead
or what we call operating expense hence the extent of investment in a sandbox
is a crucial management decision.
For every downside theres an upside
A what-if analysis is done to test a visualized or projected scenariowhat
will happen if we do X. It is akin to an experiment where the variables are
fine tuned to see what the end result will be. Imagine a situation where the
application or ERP system has gone live. Now you cannot tinker with the data
to test and conduct various what-if analyses. When you receive a new upgrade
or patch of your application, it is prudent to first test it in the sandbox
rather then implement it directly on a live client. Such recklessness might
otherwise cause your application to stall in the worst-case scenario. One cannot
preempt problems without testing new code. It helps you gain confidence that
the new code is going to be functional and will not cause any hiccups.
One area of advantage is the definite increase in return on investment (ROI).
If an application has a hundred features and we are using only 75 even though
we have paid the entire amount for the same then we are not getting sufficient
ROI. The ROI factor increases if we utilize more of the available functions.
In order to do that one needs to play around with the software.
Another viewpoint is that a lot of cost is saved when talented staff from an
in-house team starts operating the sandbox and learns the finer nuances of the
application. The dependency on external consultants reduces and is restricted
to extremely complicated functions. It also creates a deeper sense of ownership
and the implementation becomes firmly ingrained. There should be three levels
of users for each major process namely Order to Payment, Materials Management
and Planning, Production, Logistics, Sales and Distribution, Finance and Accounts,
Project Management etc. At the top-most level should be the Process Owners who
will visualize and plan enhancements with the implementation consultant or partners;
the middle level will consist of Users who will design and test the data in
the sandbox apart from keeping the existing system functional and running smoothly.
The lowest rung should be comprised of Operators who will do the repetitive
day to day entries for voucher preparation, PO, GRN, etc and forward the same
to the Users for verification, validation and authorization.
Generic applications have a standard process flow for various functions in an
integrated system. It might be beneficial for organizations to streamline these
processes by chopping off tedious steps. A regular example would be Requisition-Request
for the Quotation-Supplier Evaluation-Purchase Order Generation process. In
smaller organizations we can also work directly from the Requisition to the
Purchase Order step in case the other steps need not be documented stringently.
These process streamlining activities can be conducted in the sandbox to ascertain
whether it will give the desired outcome or not.
An interesting use of a sandbox is for the purpose of in-house training and
conducting refresher courses for users. An in-depth analysis should be done
to calculate the cost of off-site to in-house training. There is a possibility
that the first set of users during the implementation phase might quit at some
point of the project after being trained in the usage of an application. How
many times and how much money would the organization spend in training fresh
personnel? A sandbox gives a fresher the opportunity to learn hands-on before
embarking on a live client. It can also be used to train existing users to use
new features that have been implemented.
A sandbox is an interesting tool which generally gives the appearance of cost
though it is an extremely useful investment. The IT team of an organization
should strongly advocate the need for a sandbox to the management. They should
take a long term perspective since it is nothing but an unnecessary expenditure
for non-IT personnel and is conveniently overlooked. The tangible value of a
sandbox emerges only on using it actively in a real-life situation. Lot of software
glitches can be prevented in a live system through the use of one. It is a testing
bed for new processes and methodologies. Last but not the least, how will you
learn the rules unless you play?
The author works with a pharmaceutical company as Business
Systems Analyst. The views expressed here are her own and not necessarily those
of her employer. She may be reached at ipbasu@rediffmail.com
|