Professional Documents
Culture Documents
White Paper By
Tim
Sharpe
CEO
&
co-founder
tim.sharpe@sabisu.co
@timjsharpe
White Paper
Contents
1.
INTRODUCTION
...........................................................................................................
3
2.
CHALLENGES
...............................................................................................................
4
2.1.
2.2.
2.3.
2.4.
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
SELECTION
MECHANISM
........................................................................................................................................
4
COMMERCIAL
TERMS
..............................................................................................................................................
5
USER
ADOPTION
&
TRAINING
...............................................................................................................................
6
RISK
...........................................................................................................................................................................
7
PROPERTIES
OF
AN
IDEAL
APPROACH
.................................................................................................................
8
TROJAN
MICE
...........................................................................................................................................................
9
OVERVIEW
OF
THE
PROCESS
..............................................................................................................................
10
SCOPE
.....................................................................................................................................................................
11
OUTLINE
DELIVERABLES
....................................................................................................................................
12
CUSTOMER
RESPONSIBILITIES
...........................................................................................................................
13
Figures
Page 2 of 23
V1.0
White Paper
1. Introduction
Enterprise
software
is
typically
secure,
resilient
and
powerful
but
it
can
be
difficult
to
select
and
implement,
with
significant
cost
and
risk
involved.
Often
benefits
are
over-stated
and
take
some
time
to
be
seen
in
real
terms.
This
white
paper
outlines
how
its
possible
to
take
a
different
approach
by
delivering
substantial
change
in
targeted,
low
risk,
high
value
solutions.
These
solutions
are
aligned
to
business
strategy,
meet
a
genuine
need
and
carry
great
business
benefit,
yet
are
deliberately
small
in
scope.
They
are
more
easily
managed
than
large
implementations
and
carry
less
financial
and
operational
risk.
This
approach
has
been
successfully
adopted
by
the
Sabisu
team
in
delivering
the
Sabisu
platform,
resulting
in
changes
to
the
design
of
the
platform
to
help
meet
niche
requirements
easily.
This
white
paper
starts
by
looking
at
some
common
challenges
faced
when
deploying
enterprise
software,
including
software
selection,
commercial
terms
and
risk.
It
then
looks
at
the
proposed
alternative
approach
in
three
sections;
Definition o How an ideal approach would be designed to be iterative and manageable o Properties and concepts that have informed the development of the process. o Scope, outline deliverables and responsibilities for each iteration of the process. Procurement o How the procurement process must reflect the nature of innovative software solutions and their vendors. o How a well designed commercial model can be fair to all parties. A typical iteration o Key considerations for each step in the iteration. o Focus on delivering business benefit and development of a complete solution.
Page 3 of 23
V1.0
White Paper
2. Challenges
Some common challenges organisations have to overcome when selecting and deploying enterprise software.
Page 4 of 23
V1.0
White Paper
The annual maintenance cost is then based on the license typically 15% to 20% of the license cost. This maintenance cost can therefore be significant. Generally annual maintenance includes upgrades and a default level of support. Generally as usage of the software increases the cost to the enterprise increases. Therefore once the cost reaches a prohibitive level the enterprise starts to ration usage. This is somewhat counter-productive given that the software is required and is expected to deliver benefit. Wouldnt it be great if enterprise software was subject to a commercial model that encourages its propagation and increased use?
Page 5 of 23
V1.0
White Paper
Page 6 of 23
V1.0
White Paper
2.4. Risk
Enterprise
software
traditionally
carries
significant
risk
both
in
terms
of
implementation
and
operation.
Implementing
enterprise
software
should
be
low
risk;
until
the
software
is
operational
it
should
be
possible
to
change
or
even
cancel
deployment.
However,
funding
is
usually
staged,
reputations
invested
and
tight
contracts
drawn
up
so
that
mid-way
through
deployment
a
change
is
difficult
and
painful.
If
enterprise
software
was
less
expensive
to
license,
deploy
and
support,
then
organisations
could
make
more
balanced
decisions
about
the
process
of
implementation.
Often
enterprise
software
is
deployed
across
the
organization
within
a
single
project,
as
quickly
as
possible.
This
is
a
high
risk
strategy
in
terms
of
cost,
as
it
front-loads
spend,
and
schedule,
as
any
delays
resonate
through
the
plan
causing
slippage.
Its
also
high
risk
in
terms
of
operations
as
many
users
need
to
be
trained
simultaneously
or
in
quick
succession.
Wouldnt
it
be
great
if
benefit
could
be
realized
through
partial
adoption
and
throughout
a
gradual,
well-managed
deployment?
Operating
enterprise
software
should
be
low
risk;
the
software
has
probably
been
designed
and
implemented
by
experts.
However,
it
often
leads
to
increased
and
sometime
unsustainable
drains
on
funding
and
expertise
within
the
IT
function
as
the
use
of
the
software
grows.
Organisations
are
understandably
reticent
to
take
on
new
software
as
it
carries
with
it
unforeseen
overhead.
Wouldnt
it
be
great
if
enterprise
software
was
designed
to
alleviate
resource
and
funding
stress
on
the
IT
function?
Page 7 of 23
V1.0
White Paper
How an ideal approach should be designed; iterative, manageable, low risk, with high impact rapidly achieved.
This approach would choose a strategic, scalable solution but start with a small deployment focused on solving a particular problem to ensure quality and suitability. This focus ensures value is added both immediately as the current problem is resolved and in the future, as the ideal problem will be representative of others in the organization. The solution is a strategic one. Although the apparent opposite of the mass roll-out, big-bang approach required in some business transformation programmes, in fact this approach could be the essential precursor to such programmes as it reduces their risk exposure significantly. The initial deployment may be intentionally focused but the solution is strategic. Whilst often the larger transformation programmes are delivered using a specific methodology, the ideal approach would be as useful as an repeatable delivery method as it would be for a proof of concept. Indeed, the iterative model is perhaps a better way to truly achieve enterprise change, as suggested in the Trojan Mice section below; it allows constant focus on the customers. One of the benefits of starting with a low risk point solution is that the key procurement decision points can be incorporated, informing process rather than leaving it separate. The procurement process is made more efficient as a result. Enterprise software is valuable because of the problems it solves and efficiencies it introduces, so all parties benefit from realizing real business benefit as quickly as possible; theres no better way to demonstrate the platforms potential when implemented even with a small subset of customer data or small team.
Page 8 of 23
V1.0
White Paper
Page 9 of 23
V1.0
White Paper
Once this process has been completed, then its into the deployment process, which is for another white paper but will follow an iterative model with the same or similar elements. Fig.1 shows how the approach could be the basis for this.
Figure
1.
Approach
Overview
Note
that
a
pilot
-
a
pre-roll-out
stage
intended
to
ensure
that
the
roll-out
is
of
a
high
quality
-
could
be
included
into
the
Deploy
point
solution
process.
There
is
a
management
process
that
runs
in
parallel
involving
the
development
and
acceptance
of
a
proposal
to
cover
the
required
work,
along
with
an
appropriate
purchase
order.
This
would
be
complete
before
the
start
of
the
Build
phase
shown
in
Fig.1.
2012
Sabisu
Ltd
Page
10
of
23 V1.0
White Paper
3.4. Scope
The
scope
of
each
iteration
of
the
process
is
to
implement
an
iteration
resulting
in
a
fully
working
Sabisu
solution
albeit
a
solution
to
a
niche
problem.
This
could
be
a
deliverable
as
part
of
a
larger
plan,
or
a
Sabisu
proof
of
concept.
The
process
includes:
Evaluation of technical landscape to ensure Sabisu will deliver as required Installation and configuration of Sabisu On-Premise onto one hardware platform or the installation & configuration of a Sabisu On-Premise Appliance Configuration of connection to data sources typically a single data source initially Integration with Active Directory environment Creation of communities (usually 3 or 4) Creation of reporting dashboards (usually 2 pages, each with 5 widgets) System familiarisation for key users Regular review and evaluation of the implementation Support for any further engagement
In order to deliver a competitively priced, rapid proof of concept the target systems for integration are intentionally limited. The ideal strategic partner should be pleased to assist post-project by attending user groups or workshops. Indeed, the implemented product is made stronger and implementations higher quality by close involvement of developers with users. Conventional enterprise software would require a significant amount of training with each iterative delivery. This has effectively been designed out of the process by building Sabisu to be so intuitive and user friendly that users can find their own way around the system; we use modern user interface design principles to make the experience as consistent with mass market web platforms as possible. If the scope is to deliver a proof of concept the objective is to leave the customer with a solution that users can interact with as they would a full implementation; its not expected that the customer will be sufficiently familiar with the platform that they can carry out complex configuration activities this tends to naturally follow in subsequent phases.
Page 11 of 23
V1.0
White Paper
Page 12 of 23
V1.0
White Paper
Page 13 of 23
V1.0
White Paper
4. Procurement Considerations
Procurement processes are often not optimized for the purchasing of innovative software solutions. This section discusses how they can adjust.
With all these factors taken into account the likelihood of creating a strategic partnership is good.
Page 14 of 23
V1.0
White Paper
Some services essential to the engagement, build and deployment will be costed into any proof of concept proposal. All commercial negotiations are open book and transparent as they should be with a trusted, strategic partner.
Page 15 of 23
V1.0
White Paper
5. Step-by-Step Guide
Key considerations for each step in an typical iteration, focusing on delivering business benefit and development of a complete solution.
Limiting
the
scope
to
high
value
problems
such
as
these
will
allow
the
maximum
benefit
to
be
delivered
and
the
solutions
potential
to
be
demonstrated.
Even
if
the
number
of
users
affected
is
initially
small
this
approach
can
deliver
great
benefit.
Its
important
that
the
solution
is
applicable
to
other
problems
in
the
future.
Examples
of
niche
problems
appropriate
for
proving
Sabisu
have
included;
Energy Usage Monitoring o Make energy usage data from data historian available to management team o Proved integration, presentation and collaboration capabiliities of Sabisu o Precise measurement and reporting problem o Significant benefit as any energy saving has significant cost impact o Small, focused team Digital Signage o Make key operational data available on public screens around organisation o Proved integration and presentation capabilities of Sabisu o Low risk, high visibility and impact o Small deployment o Limited number of specific KPIs to address Shift Management o Deliver Shift Logging capability alongside operational data for Shift Management team o Proved integration, collaboration and rapid development capability of Sabisu o Operational impact o Small, focused team of Shift Managers o Senior management relevance o Opportunity to exploit integration capabilities of Sabisu. Page
16
of
23 V1.0
White Paper
Page 17 of 23
V1.0
White Paper
Other
subjects
may
be
too
sensitive
to
yield
useful
information,
including
return
in
investment,
business
growth,
cost
savings
or
so
on.
As
with
any
other
enterprise
software
procurement
you
should
aim
to
determine
whether
the
vendor
is
a
candidate
for
strategic
partnership.
For
example:
How can the vendor share the risk of adopting the new technology? What expertise can the vendor commit to supporting the implementation? How can the implementation be frequently assessed to ensure suitability and capability of the solution? What is the strategic plan for the solution, product and/or vendor organization?
Your enterprise software vendor shouldnt just expect these questions; any vendor committed to a strategic partnership should recommend you ask them of all other enterprise software vendors.
Page 18 of 23
V1.0
White Paper
Sabisu is designed in such a way as to make this a rapid process exactly the opposite to enterprise software which seeks to maximize services revenue. Following this a small number of user communities are created within Sabisu, each holding a small number of users necessary to support development. These communities will expand organically as more users are required to test. As this is a point solution to a specific problem its low risk and suitable for a collaborative, iterative approach. Therefore its common to have developers work closely with end-users to ensure that the solution meets their requirements. Another factor supporting the iterative approach and one of the advantages of implementing a platform like Sabisu - is that theres no development as such; the solution is provided as a number of components that are constructed rapidly in a dedicated Sabisu development environment. In cases where custom development is required using the Sabisu API, the iterative approach holds. Whilst the use of a development environment like Visual Studio may be required, Sabisus API makes the development much easier and allows for a rapid rate of progress. During the development process it might be appropriate to release beta versions of the solution to selected users. This is easily accommodated by setting up a pre-release user community and making the solution available to those within it. When the solution is ready to be published the developer simply makes the elements available to the wider user community.
Page 19 of 23
V1.0
White Paper
Page 20 of 23
V1.0
White Paper
Page 21 of 23
V1.0
White Paper
5.7. Review
After
feedback
has
been
gathered
its
appropriate
to
review
progress
and
look
ahead
with
a
view
to
maintaining
the
momentum
already
built.
In
addition
to
user
and
management
feedback,
Sabisu
is
unique
in
that
it
can
be
used
to
demonstrate
genuine
system
usage;
amount
of
data
shared,
widgets
in
use,
messages
left,
chats
initiated
and
so
on.
This
allows
future
deployments
to
be
better
planned,
whether
in
problem
selection,
solution
development
or
deployment
itself.
The
review
process
should
involve
senior
management;
at
this
stage
the
senior
management
team
have
either
been
involved
throughout,
or
appraised
of
success
in
the
Seek
Feedback
step
immediately
before.
This
is
a
great
opportunity
to
engage
them
at
the
start
of
the
next
process.
The
review
process
may
be
completed
in
a
single
meeting
with
all
stakeholders.
Items
that
should
be
reviewed
include:
System usage o How was the system used? o How could the effort and financial investment made so far be further leveraged? o Did anything prevent wider usage? o Were some aspects particularly successful? Lessons learned o Could the implementation have been smoother? o Are there any aspects of the process that would be useful in other projects? o Are there outstanding actions that should be carried through to other projects, deployments or business as usual? Strategic fit o Are the original assumptions on strategic fit still valid? o Have any external factors arisen which change the assessment of strategic fit? Evaluation of any new requirements raised during the implementation Identification of well-defined, high impact business problems that should be addressed next
Page 22 of 23
V1.0
White Paper
Page 23 of 23
V1.0