This is the personal blog of Tasos Christidis. Evolved from a general technology blog to a cloud- and XaaS-focused resource. Special references to Software as a Service.
You can also reach me at LinkedIn: http://gr.linkedin.com/in/anastasioschristidis
Subscribe to this blog
Follow by Email
What does “Quality” mean for SaaS products?
anything sold, quality is the first and most important factor for its success
on the market (price is the second most important thing, but we will not deal
with it, in this post). During my engagement with the Software as a Service
business I have found out that Quality is an issue that needs to be redefined
in that context. I started thinking about this, driven by the fact that “traditional”
software “virtues” are not enough to build a sustainable SaaS income. By the
term “traditional” I mean all the usual quality elements or performance
indicators that the buyer expects from any kind of software (SaaS or not-SaaS):
be fast and reliable
be adequately supported by its vendor
provide insight to the data that it keeps (and not just to… keep them)
point in this post is that SaaS is a space where additional “quality elements”
must be in place. I will enumerate what I have come across (and what my
customers are usually challenge me on) and explain why they are considered so
much more important than traditional in-premise offerings.
Extensive parameterization: A SaaS product must offer
extensive parameterization options since it is by definition a piece of
software that the end-customer cannot be endlessly customizing and at the same
time not respecting physical or logical constraints that its creator has set.
Consider one of my favorite silly examples: In a customized in-premise
software, if accounting dept wishes, it can revert the debits and credits on
the General Ledger module so that the debits are on the right and the credits
on the left hand side (!). Imagine this requirement being served by a generic
SaaS Accounting software. Either the software vendor will say “not possible, sorry”
or they will create a new customer setting like this: “debits on the right: [YES]/[NO]”.
The point is that in order to serve
diverse customer requirements from a unique codebase (and database) the logical
architecture of the system must be extensively based on parameters and
User support: By definition, any SaaS business
shows meaningful profit margin for the supplier only if the number of customers
is high. A large number of customers increases the workload of the Support
department (call center, web support, telephone hot-line etc.). The vendor needs to build mechanisms that
are capable of supporting multiple users, simultaneously. This is not
necessarily the case with traditional in-premise software where an on-site
technician visit is probably the best (or only?) way to identify and resolve
the issue. In such cases, there is a mechanism to pipeline, schedule and
execute the visit. And no one expect the visit to take place instantly!
Frequency of new releases: All software vendors offer
frequent upgrades and new releases for their software. In-premise software
suppliers do so only if the customer has bought a Maintenance Contract, but in
the SaaS business new releases are not something that could be charged for an
extra fee; it is simply expected to be included in the monthly (or whatever)
recurring fee. To put in different words, there is no SaaS product without a
release upgrade “package” attached to it. But that’s not the main point here.
The main point is that in order to be constantly on the edge, to be ahead of
the competition (remember: SaaS is the tool that enables users to easily switch
from one product to another, since they never “bought” anything) and to follow
versions, mobile environments etc.) a
SaaS “factory” must constantly produce new and better releases of the software.
The urgency of new releases in in-premise software is not that big, since what
“used to work a few years ago” will still work unless a major PC switch is done
(not a frequent case!)
Performance issues: The workload of an in-premise
software & database is generally stable with slow rate of increase.
Performance bottlenecks or degradation manifest themselves slowly, gradually
and always give enough time to IT dept. to react. This is not the case in SaaS
where the hunt for new customers (=users) in that existing infrastructure in
endless. Sure, modern architectures provide all the necessary tools for scalability,
high availability and fast upgrades. But in any case this means that the SaaS vendors must have the mechanism to
be on top of these issues; and they are rated by their customers on this
Security: Much has been said about the
security of SaaS. We shall not go into details here, but just remind the usual
concern of the customers: “my data is in the cloud and therefore out of my
physical reach and protection”. SaaS
vendors must demonstrate impeccable positive records in terms of security.
As simple as that.
Customer engagement: Because SaaS does not require any
capital investment, it is a perfect tool for customers to test and adopt, if
they finally get convinced that it suits their purpose. On the opposite case,
they are free to abandon the service and search elsewhere. This creates a high
velocity of customer transfer in and out of the service, or “churn”. In order
to minimize the rate of customer movement out of your service you must be in
constant contact with them. Listening to criticism, to their problems, trying
to find work-arounds for problems that they see as system inefficiencies,
keeping them up to speed with new releases and versions (that must come very
frequently, as stated before), etc. Therefore, there is a quantity of customer
engagement work that did not exist with traditional in-premise software sales.
Back in the day – and for large accounts only – it was enough for the account
manager to visit the customer every once in a while, discuss issues and find
solutions to new problems. In SaaS it is
not enough. Most SaaS vendors are employing social media and other techniques
to keep a high degree of customer engagement.
successful SaaS business implies the existence of additional (new to the
market) product virtues. Ultimately, these will separate the “men from the
boys” of the SaaS space, because as competition rises, buyers become more aware
of these additional virtues and start demanding them instead of just seeking
them. The pressure in SaaS suppliers is building up and each vendor will select
some (or all?) fields to build expertise and trust.
between customers and providers in the cloud business are generally governed by
the Service Level Agreement or SLA. In a previous post I made the point that a
really “tough” SLA is probably not the “holy grail” of the cloud business,
which every customer should be looking for. In this post I will continue the
same line of thought, focusing this time in the impact that a strict SLA has on
the customer organization itself. For this purpose, I will use the term “Reverse
In the organization’s
journey from an on-premise Business Application setup to a Software as a
Service one, one of the key factors of success is data migration. Of
course, one starts with basic questions like “do I want or need to move to the cloud?”, “Which is the best SaaS solution
for my case?”, “Does it address my special requirements?”, “am I content with
the reporting/BI capabilities that it offers?” etc. But having answered all
of the above, you should take into consideration the data migration issue. This post will point
out some very significant issues around this subject, which you need to address
and examine; probably in close co-operation with the SaaS vendor of your
choice, before accepting their financial proposal and start the journey.
In an older post (http://goo.gl/jXGmOi) I discussed how web-based or cloud Financial
ERP can help you unlock new possibilities for your Business Processes. The
basic argument there was that an open system (like a cloud-based system is, by
definition) could involve your customers in a specific business process (like
sending a Sales Order, posting a comment that needs subsequent action from
within your CRM etc.). The reaction I got from a number of
readers was that new best practices could be devised and applied in a very important,
so to speak, business process which is of everybody’s interest, big or small:
that of invoicing the end-customer. We shouldn’t forget that many small and
medium enterprises are focusing their I.T. operations on Accounts Receivable, inside
which the invoicing cycle represents a significant part. Therefore, in this
post I’d like to focus on this specific issue: how can your invoicing change when you’re using a web-based Financial