Tasos Christidis

SaaS Applications and their “community” nature (part 2)

2011-10-23T09:09:00.001+03:00

In the previous post we saw what makes a SaaS space, a “community”: It’s a collection of people with similar business competencies and/or similar everyday issues pertinent to the SaaS application that they are using. We also discussed that it is only in the SaaS world that these users have the technical capability to instantly interact (in any other application community, they would have to meet each other in separate blogs, forums etc.)

Today, we shall give some practical ideas of how this community could interact and share and the topics of that conversation.

Implement “user group news”: The SaaS desktop could provide a special space where news and alerts regarding the application would be released or communicated, for all users to read through. For example, new functionality that was added, explanations about a recent slowdown event, new pricing policies on behalf of the vendor are just some examples of what the “user group news” could be about.
The easiest way to do this, outside the SaaS space is through a dedicated blog of the SaaS vendor, on their web site etc. But, from personal experience I can assume that not many users would be eager to visit that blog each day and find out what’s new. Instead, if they had these news “popped up” upon their login in the system, you would be almost certain that they would have read about it.

Provide news feeds and other sources of information: Apart from what the SaaS vendor has to say about the “space”, there are other sources of useful information. Regardless of whether we are talking about a vertical implementation (e.g. Facilities Management contract management system) or a horizontal one (e.g. Accounting software for the SMB), RSS sources or Tweets from relevant companies and organizations could be incorporated in that SaaS desktop. Each user that has been interested in the past probably knows these sources. But, again, wouldn’t it be easier to bring these sources in the SaaS desktop? After all, let’s not forget that you, as a SaaS vendor, are always seeking new ways of keeping the users inside your space; not letting them wonder around “wild internet”.
In addition, the application should allow the user to adjust their personal favorites; change RSS sources, add more etc. And even, share these sources with the community (see “virtual forum”, below)

Enable chatting inside the application: When a user faces an urgent problem, perhaps they don’t have the time to investigate or call the SaaS vendor for telephone support. Chatting between users of the workspace could provide a solution to this problem: What if you could instantly chat with your colleague who operates in another branch of your company, or in another geographical location, asking for help: “how do I do this?”, “I’m stuck with this procedure and on-line help doesn’t help me much”, “have you ever seen…?” are just a few questions that may find fast and easy answers, without the help of the vendor.

Implement a virtual forum workspace: No matter how good the SaaS application is, there will always be room for enhancements and problem solving. A virtual workspace is the means to collect these requirements. Bugs usually show up in the user’s everyday operations and not on the programmer’s test cases. The user is the one that can quickly alert the community for the bugs and probably suggest a workaround. Also, when a commonly required enhancement exists, it is in the forum that the SaaS vendor will see the wider requirement and how critical it is for the benefit of the platform. And this may lead to faster resolution of the issue.
Again, such service could be provided by a blog or a forum in the web site of the vendor (e.g. ZOHO CRM), but what better place to store that knowledge than the SaaS workspace itself. And finally, the resolution of the issue could be transmitted to the community in just seconds (remember that in that SaaS space, everybody has a named user profile and a declared email!)

Establish on-line “question and answer” capability: A variant of the above line of thinking is this if the “Q&A” functionality: Assuming that one user’s question is also others’, if that user posted a relevant question and somebody (vendor or co-user) answered, then everybody would instantly receive that knowledge.
If we try to imagine the evolution of this, we could end up with a solid “knowledge database” in our hands. Technical tools such as “full text search” would allow everybody to do a “fuzzy” search in the issues that have been discussed.

I thing we’ve made our case: Any SaaS workspace is a potential community and technology can serve as an enabler of problem solving inside the boundaries of that community. In one of my next posts, I will go one step further and talk about co-operation and synergies between SaaS tenants. After all, a “community” is not just a collection of people who “help” each other. It is also a collection of people who may work together for their common good…

SaaS Applications and their “community” nature

2011-10-15T09:10:00.001+03:00

Any SaaS service is the gathering space or meeting point of a large (hopefully!) number of users. Depending on the scope of the application, these users may belong to similar business spaces/ventures/competencies or not. Even if they don’t, they share at least some kind of appreciation for the benefits of SaaS (such as lowering actual costs, real time access from anywhere etc.).

One more aspect in what these users are sharing is the everyday issues that they face with the usage of the application. Known bugs, common functionality enhancements, user interface issues etc. Who is better equipped to help you, than your co-user in the same SaaS space? Yes, you would expect that the application is equipped with some on-line help or perhaps a written user’s manual. But, SaaS applications are moving at the edge of technology and functional updates and upgrades are being done very often; much too often for a written document to keep up. Keeping a written user’s manual up-to-date is very hard and on-line help can’t incorporate a variety of issues related to “this” or “that” function. They usually address common issues and most common mistakes and workarounds. In addition, one can assume that any SaaS application is much more parametrical than your usual in-premise, custom-developed system. Therefore, issues that have been “hard-coded” in your previous application, may require the setting up of a couple of parameters in that new SaaS platform. Therefore, it’s even more difficult for the vendor to produce some kind of “user’s manual” which will address all the details and combinations of parameterization. From personal experience, I know that not all parameter settings have been tested and verified, since just 10 “Yes/No” parameters, combined to each other will produce thousands or millions of combinations.

These two facts – the common business competencies and the common everyday usage issues – drive us to the inevitable conclusion that all those users form a kind of “community”, that is a collection of people with common interests and goals. Yes, you may say that it’s the same thing with all other in-premise applications (the SAP community, the PeopleSoft community etc.) and you are probably right. But, it is only in the SaaS space that the community members have the technical capability to interact and share knowledge and experiences. After all, isn’t that what you do with facebook, linkedin and other social media? You participate in a community of users, to expand the circle of friends, co-operators, seek new business opportunities etc.? Well, imagine doing the same thing from within your SaaS application…

In the next post, we shall explore some ways of actually achieving the formation of a “SaaS community” and how this can help you in many ways.

Signing up and adopting a SaaS application

2011-09-24T10:29:00.000+03:00

When we are talking about SaaS, we usually mean software applications, offered to the end user through internet and operated in a web browser. SaaS delivery model uses the “cloud space” in order to reach out to the end user. This means that when you sign up to such a service, you can’t really be sure where the actual server resides. It could be as far as the other side of the Atlantic Ocean, for all you know!

Therefore, in some cases, the traditional sales model of “salesperson demos to your premises and then fetches a signed contract to you” does not work. Local representation may not exist in your geographical area and the only way to sign up for these services is through the vendor’s web site: Typically, you will order the number of users that you wish, enter your company’s name and finally “check out” from the “e-shop” using your credit card or other payment service.

Sounds simple, as simple as buying a book from Amazon, but it isn’t! There are a number of issues that are raised; issues that simply do not exist in a typical e-shop transaction, when buying books or electronic appliances. Let’s go through of them, starting from the pre-sales stage and reaching the after-sales support process:

Sales process: When the SaaS vendor does not have local presence in your area, the only way to learn more about the product is word-of-mouth, internet research, video on YouTube or live web demos. All this is good enough, but there can’t be that face-to-face contact which always makes discussion easier and clears up issues faster and easier. Obviously, when you are buying a book from the internet, you have no need for such discussion and “eye contact” but when it comes to a long or medium term engagement, you probably need to be convinced. What the vendor can do to provide all the details on their web site and be able to answer more of your questions through email or telephone contact.

Service Level Agreement: In the traditional in-premise model, there usually is a signed contract between your company and the vendor. That contract tackles all technicalities of the cooperation between two companies. In the case of remote SaaS vendors, there is only a SLA, which is accessible through their web site and you either accept or reject. There is no room for negotiations, whatsoever. So, you have to ask yourself (and probably your attorney!) if that SLA is enough for you to base your business on.

Initial training: While system installation is not an issue in a SaaS product, training may be. In a typical in-premise proposal, there is always some reference to “training services” that your vendor offers to you, for the system start-up. In the cloud space there probably aren’t any trainers near you. Therefore, you have to do self-training or CBT or watch videos that your vendor is offering to you or simply “dive into the deep”, yourself (that last option is doable in some simple software, such as an appointment management system, light CRM etc. But what about a cloud-based ERP?)

Uploading of existing data: If you are migrating from an older system to a SaaS application, you will most probably have a wealth of data that you need transferred to the new system: customer records, accounting balances etc. You can be sure that your vendor has some uploading service facility in their software, but again you are on your own: you have to comply with given file layouts (there is probably zero maneuvering capacity from the vendor side; otherwise they would spend all of their time working on custom interfaces with their customers). You have to read and understand interface specifications and then produce the output files for these specifications. Erroneous files will simply be returned to you for amendments and re-transmission.

Fine tuning and parameterization: I’ve blogged before about how parametrical a SaaS application should be. Its mission is to cater for several and diverse business models and preferences. Therefore, I expect that any SaaS application needs a larger number of parameters to “describe” or “configure” each of the functions. This can be a real headache for the buyer, especially if they used to use a low-cost, in-premise, custom system. Again, there is the issue of how the vendor’s consultants “discover” these diversities and different requirements. From my experience, it takes exactly this: a “discovery document” that runs the business functions one by one and, while the buyer provides his business-flavored answers, the vendor’s consultant translates them into system parameters.

Customer support: It is very probable that your SaaS vendor resides in another country, speaking different languages and probably be on a different time zone. The obvious “hot-line telephone support” may not be present. You have to make sure that the vendor has in place a solid customer support web service (if not a 24h service telephone line). Especially the latter is a costly service the existence of which is not obvious. Or, you may have to pay extra fees to enjoy such a service.

The above make it obvious that in the SaaS delivery model, there is the question of local representation of the vendor. That is not to say that overseas vendors are to be rejected. You just need to research and decide what the extra effort will be for you to adopt the SaaS application and balance it with the unchallengeable pros of SaaS.

email and SMS in business applications

2011-05-29T12:01:00.001+03:00

I recently had the opportunity to work in a couple of projects that evolved around “alternative means” of User Interface, other than the screen and keyboard of a typical PC. Also, the use of tablet PCs and PDAs was not the answer to the questions at hand.

The level of computer literacy of the users was one issue: There was a number of people that a) were mobile and b) had no or little knowledge and skills of modern user interfaces. The actions that needed to be performed by them were relatively simple, meaning that the User Interface was to be quite simple. In fact, they were required to provide simple “yes/no” answers to a number of questions. For those people the solution of simple text (SMS) messaging was selected. Here is the list of advantages that SMS messaging has:

Not everybody has a smart phone or PDA, but everybody has even the simplest mobile phone which can send and receive SMS.

Texting a message can be a real pain but when you have to simply answer Yes/No type of questions it’s quite easy and fast.

SMS are cheaper than a permanent mobile web connection.

In case of reimbursement of the cost, it’s very easy to measure usage and reimburse cash to the user.

SMS are much easier to digest for the not-so-literate user.

Another application of SMS is the inbound messages. Let’s have a look at the example of booking of appointments: What if you were a service provider (e.g. a car repair shop or beauty parlor) and needed to open your work schedule to your customers, to book an appointment by themselves? The first obvious choice would be this of a web-based application which would present your schedule in a web site, show the open slots and let customers book an appointment. But, that way, you would provide no service to non-computer-literate people (and there are a number of enterprises that target on this kind of people!). So, what if you could be able to accept SMS messages and convert them to appointments, which would them fill in your computer-based work schedule?

Email has definitely its place in this discussion: Of course, you could (and probably are doing it right now!) accept messages, inquiries and complaints from your web site (most enterprises are using the classic “contact us” form). But you could display even more “openness” if you provided the ability to accept direct email messages; you could probably setup a couple of email accounts, such as complaints@acme.com and internetsales@acme.com and split the inbound messages per area of interest. Now, what if you could instantly download those emails to your CRM and match them with existing customer records; or create new customer records and sales leads? No doubt, this would save your time and money from the manual or semi-manual processing that you are doing today.

Finally, there is the area of the outbound email communication with your customers, suppliers etc. There is a number of issues that emerge from the processing of your ERP, CRM or any other type of enterprise application. You could certainly gain time and effort if you could send emails with issues (and supporting documentation, originating from your application) to the interested party, customer or supplier. For example, email a copy of a problematic invoice to your supplier or ask for a late payment to be expedited.

That is to say, that alternate media of communication such as the “humble” email and SMS are now an integral part of your business applications. And while this is more or less obvious for a CRM type of application, there is a number of ERP or legacy applications that have yet some ground to cover. While integrating a web-based application with emails and SMS seems like a trivial task, there is a number of issues when we are talking about legacy applications, mainframe systems or other “closed” environments. But there is also some opportunity…

Customer perception about IT Professional Services in the Greek market

2011-05-08T12:40:00.000+03:00

For all of us working in the software services sector in Greece, it is clear that the effort of computerizing the Enterprise does not end with the installation of the software. After the software has been “sold and purchased” (either in the traditional delivery model or in the SaaS model) there is, or can be, a series of actions that take place, in the form of Professional Services. These services typically include:

Start-up services for the initial parameterization of the business application (standard packaged products such as office suites are excluded from this category). During this cycle, some very basic questions need to be answered, like what are the geographical locations of the serviced entity, what are the cost centers, what are the taxation schemes that are going to be used in purchasing and selling goods and services etc. One very common misunderstanding on behalf of the end-user is that – because these issues, given time, have become trivial for them – they are also trivial for the software vendor and so such start-up services should be offered a) free of charge and b) for as long time as needed to accurately describe all aspects of the business model of the said entity.
They couldn’t be more wrong because the vendor will – at best – use own judgment to tackle these issues (with not the best results, at times) or – at worst – will do nothing to tackle them (since they could very well be unknown to them!).

Initial loading of data is among the first problems that software companies face when starting up a new installation. For every kind of software that someone is marketing, we can assume that they have built-in functions for the initial uploading of data, in case the customer is replacing an older system. Customer data in case of CRM systems, accounting data in case of financial systems, warehouse data in case of ERP are just three of the most common cases that we face every day. The customer’s expectation that existing data should be uploaded in the new system is just and reasonable. What they sometimes fail to see is that the target system (the new one) has obviously a working set of uploading programs and procedures that cannot be “bent and twisted” for each new customer case. It is the customer’s responsibility to provide good, readable data to be uploaded to the target system. Otherwise, the vendor can do it for them… yes, for a price!

Training for the end users. This issue has two different angles:
- First of all, the customer needs to understand who is going to be initially trained: Are all the users part of the training program (even those residing in distant geographical locations?) or is this going to be a “train the trainer” approach?
- Secondly it has to be clear that the initial training will of course cover all aspects of the “standard system” but will probably not include any special reference to the specific business problems or issues that the customer is facing. These are things that a software trainer simply cannot know and solve. They are the responsibility of a business consultant and they most probably have to follow another training cycle, different from this of the “system start-up phase”.
These issues can very easily lead to misunderstandings and false expectations from the “start-up training program”, especially in the most common case where the vendor will require additional fees for additional training services. It is safe to assume that the initial training will be part of the “purchasing package” (or, if not, then there should be a clear reference to the relevant cost on the Software Offer that is displayed to the customer). But additional training (asked for after weeks or months since the system start-up) will incur additional fees.

Customization is another pain point on software deals. “How much” business-specific intelligence should the initial system provide, out of the box? How many different business cases? How may reports and dashboards? Should “this” or “that” be part of the standard release of the software? Customers (software buyers) tend to see themselves as “business models” (at least in their specific industry) and believe that all of their specific business rules and requirements should be mapped or constructed on the initial solution. In most cases (at least according to my experience) the problem is not the hourly or daily cost of “customization professional services” but the very existence of them!

Telephone support is the kind of service that will surely be needed at some in time, even in the simplest business case (where customization is zero and additional training is minimum). Telephone support is a kind of tool that keeps the software running with fast and easy answers and also low cost for the vendor end. But, being such a wonderful tool must come at some expense. Again, one common misunderstanding is that since I bought your software there must be someone “out there” to help me, 24x7. It is often not clear that purchasing the software does not mean that you have purchased unlimited hours of free telephone support because the call center employees have some payroll and training cost. And this cannot be part of the initial business deal, since the hours of the engagement cannot be predicted, per case!

All of the above are significant sources of revenue for the software provider and most of them are far beyond the scope of the initial software purchase. There have been numerous cases where customer expectations reach and even exceed those limits and for an expected zero cost. This is a Greek phenomenon that, in my humble opinion, has been the result of many years of “price wars” among software companies. In their effort to acquire bigger and bigger market shares, some companies offered “more for less”. This resulted in a general “educational result” for the customers that comes down to “software costs a little and professional services cost nothing, since they are part of the vendor’s effort to get and retain happy customers”. This does not happen in other parts of the world where it is clear that the software itself encloses some quantity of brains and experience but the following professional services include much of the same.

Greece’s Educational System problem

2011-04-10T12:26:00.000+03:00

Today, I am going to talk about an issue of more general interest: the educational system of Greece and more particularly how it can be “sanitized” and cleared up from problems that have been around for decades. I believe that I’m entitled to speak about it, using my characteristic of “dad”, “recruiter of young professionals” and “physicist by education”; not to mention “married to a teacher”!

Well, to cut a long way short, here is a list of things to do or change in the Greek Educational System:

Decrease central government expenditure for Education, by 30%

Decrease number of schools by 20%

Decrease number of teachers by 20%

Make sure that all high-school and Lyceum teachers hold an M.Sc.

Install serious teacher evaluation mechanisms. At the same time, give back to the teachers the high social status that they deserve.

Move the economy of schools under the roof of the municipality, instead that of the central government

If economic crisis hits, then give 20% of the teachers a mandatory sabbatical (with no pay)

Stop the madness of “private afternoon schools – frontistiria”.

There you have it: the solution to the county’s over-expensive, under-productive Educational System.

“Are you mad?” some of you will say (or maybe all of you!). No, dear friends, I am not mad and I can prove it: This is what Finland has done and its Educational System is among the best in Europe and on the planet! “Are they mad?” you may ask again. No, dear friends, the people of Finland are not crazy, either. They did it and it worked. Period. (although “frontistiria” has always been an unknown word to them…)

Oops, I forgot to mention that in that country there is a serious surplus of social solidarity and almost zero corruption. So, when they are told that “we have a problem and you need to help your country” they just… do it.

User Role in SaaS pricing models

2011-04-05T21:14:00.000+03:00

SaaS pricing models may be based in a number of factors, or even combination of factors. For example, an ERP application may be priced per seat (per user) while a retail banking application may be priced on a transaction basis. A Sales Force Automation application may be priced on a generated-revenue basis etc.

I can’t help thinking, though, that even the simplest business application has different “user roles”. Perhaps, an advanced role that does most of the tasks and a lighter role that only executes a few trivial tasks. There may be another “super user” role that has access to the system parameters. There are more examples like that, but I think you get the point.

Having said that, I would – as a SaaS buyer – go into the temptation to ask for special discounts for those “low level” roles. The reasoning behind this is that I will activate some users that a) add no significant load on the system and b) give my enterprise relatively low value (compared to high authority, “do-it-all” users). Therefore, I would not be willing to pay the same amount of money for these users and you (the SaaS vendor) should not ask for the same amount of money.

Right? I’m not sure… See, while adding the “significance” of the user role in the SaaS pricing scheme seems logical, it can backfire on you: You have to be clear as to what your pricing tiers are; which kind of users fits in what tier. Precisely define the fine line between role “A” and role “B”. And you have to be precise, otherwise the potential customer may argue that “John Doe can’t be considered a high user because he…” and “Jane Doe is surely not a system administrator since she…”. See what happened? In your effort to establish a more “fair” pricelist, you have opened doors for prospects to challenge your tactics, your reasoning, your very pricelist.

For the above reasons, I would suggest that applying “user role tiers” in your pricing policy may not be a good way to become competitive. You may want to consider other, simpler pricing schemes but, surely, schemes that are based on undisputable entities, such as “number of users”, “number of modules”, “Gigabytes used” etc.

Mechanizing large sales networks

2011-03-12T18:58:00.001+02:00

These days, there is a lot of discussion around the benefits that could software has on Small/Medium Enterprises (SMEs); and it does! But today, I’d like to focus on another area that SaaS could have great impact on: the case of large sales networks.

First of all, let me define what I am focusing on: A large sales network is a distributed network that sells a specific range of products and/or services in a large geographical scale and/or from a large number of outlets (outlet being a dealership, a franchisee etc.). Usually, this network is operated by a “big” enterprise (not an SME), such as an exclusive importer in a country or the franchisor etc. Up until today – because of the fact that the network operator is a large enterprise – it is more than likely that software systems have been deployed by this entity to mechanize this or the other network operation. Some typical functions that the Operator would like to streamline are incoming sales orders from the network, visibility of stocks across that network etc. If the operator has been around for some time, it is more than likely that they have deployed some kind customized web-based system to execute these functions. They have either developed it in-house or they have purchased some customizable platform.

Having defined the scope of this discussion, let’s see what are the challenges that these networks are facing and how SaaS can help them:

Unified customer database :If the network needs to have instant access on all customers, regardless of their initial geographical show-up and have a clear picture of the customer’s previous transactions with that network, then we are talking about a unified customer database. And this cannot be achieved using stand-alone software deployments in each and every outlet of the network; unless you want to consider replicating customer data from all locations to all locations. I have seen this and, in my opinion, it does not work.
But if the outlets were working in a multi-tenant SaaS environment, they could have access to one common customer database, while still keeping their privacy on other, more personal data (such as volume of sales, local accounting etc.). Naysayers will argue that sharing the customer database is a bad practice; and maybe they are right – in case of competing outlets. But it is possible that the outlets are not in fact competing with each other if, for example, the outlets are geographically too far apart. Anyway, this is business discussion which does not concern the technology issue that we are discussing here.

Customer experience :It is more than probable that you want your customers to enjoy the same (exceptional?!) experience when they are doing business with your network. For example, you need all price quotes to have the same look’n’feel, printed in a format that you have pre-approved and including all disclaimers that your – central – sales policies require. Another example is the seasonal discounts that you may give to a range of products or customer profiles: How can you be sure that all points-of-sale will abide to this or that sales policy? What if the sales software that produces sales quote was controlled by you, centrally, and you were able to setup discount policies…

Software upgrades :This is not an issue for your sales process, but unfortunately it is an issue that you have to cope with. If your points-of-sale were “islands of technology” and there was a new software feature that you’d like to deploy or a bug that required immediate response, handling of a large number of them (and probably in different time zones or languages) could be a pain. Of course, today’s technology has addressed this issue in many ways, but it is my belief that no solution is better than this of the cloud software “instant deployment” feature. If you upgrade you central server, then everybody gains instant access to that new feature.

There are more comments that one could make on this issue, but using a little of technology and a little of the sales process itself, I think it is now evident how an architecture of centralized software can help the network operator. Now, there is one more question to answer: this deployment will be done on a private or public cloud? This is a question that I’ll try to answer in one of my next posts.

Automation of sales process in SaaS (part 2)

2011-03-05T12:28:00.001+02:00

Automation of the on-boarding of new users on a SaaS platform is quite important and new. This is the kind of problem that does not exist in the traditional on-premise delivery model. So, it drives the SaaS vendor to “think differently” – and accumulate some costs in the process (!).

It’s not just about “on-boarding”. If we discussed this issue more widely, we would talk about automation of the entire sales process. And while we are at it, we could also expand the discussion on the automation of the after-sales process, too (customer support, in this case).

Let’s see some more challenges:

Since there is no license sold but there is obviously a SLA, how can this be documented? In the traditional on-premise, license-based model, the buyer signs a contract that they have actually purchased and own this or that piece of software. In the world of SaaS, the buyer does not own anything… Well, that’s not true! They own, at least, their data, which are inputted on the remote, hosted SaaS application. Anyway, how do you automate the “purchasing of SaaS services” with the absence of a written contract? A SLA? Something! Do you activate a simple “pay with your credit card and enter the site” process? And what are lawyers saying about this? I will not go into legal details, as I am not the right person to do so. Anyway, it seems that not even lawyers can agree amongst themselves. The message being here: Should/Can the SaaS vendor create a mechanism where potential users pay through their credits cards and just “enter the site”?

Now, let’s assume that you, the customer, have overcome the previous problem. You somehow paid for the service and now you have a user name and a password. What do you do with this? (!) If you bought the service on-line, you are obviously not getting any training from a trainer. This is another problem that the SaaS vendor has to solve: training of the remote, anonymous users. There is a number of ways to do this: provide extensive user manuals (and not just a typical “quick-reference guide”) or e-Learning modules (CBT’s, we used to call them!) or extensive on-line help inside the application itself. Everybody can understand that all of the above will incur more costs and increase time-to-market for a new SaaS venture. On that, you have to add the – logical – assumption that, exactly because of its SaaS nature, the application needs to be very parametrical with a lot of configuration options; stuff that a simple stand-alone application may not have included in the first place.
One of my favorite examples is this: A credit note of a sales invoice should debit the sales account or credit it with a negative sign? Do not try to answer this question! Accountants are divided to 50%-50% on that matter. No technical guy can ever solve this problem… unless you gave them a system parameter/option that controls this behavior. That way, everybody will be happy! Do you see where I’m getting at?

Let’s see now the issue of customer support: After you have concluded the sale and the users are trained (or self-trained), problems/issues arise. They require some customer support. How does the SaaS vendor organize their customer support function? First of all, let’s try to remember that this, being a SaaS application, will be spread to users, all over the globe (if you are lucky enough!). Therefore, your Customer Support team must work on 24h shifts. This will drive costs sky-high and that’s why you need another (additional or primary – you choose) mechanism for customer support: Some kind of web system where users will post their comments/issues/problems and they will be handled in a proper manner (whatever you decide “proper” is). Therefore, the challenges here are to actually have and maintain a “customer support” web system, different from the actual SaaS platform and of course providing instant access to newcomers on your cloud.

In the SaaS world there are new issues emerging, from the side of the vendor, too. It’s not just about building an application and getting it to work… Nobody said it’s going to be easy; but it’s going to be a lot of fun!

Automation of sales process in SaaS (part 1)

2011-02-19T11:56:00.001+02:00

Can the process of boarding new users in a SaaS application be automated? When deploying a big on-premise ERP or a customized CRM etc. one can surely expect that the system installation, parameterization and deployment will not be a matter of minutes! It will take consulting and the provision of other services before you can say that you have a truly operational system.

In my opinion, SaaS is (should be) trying to tackle this issue, too. It’s not just about a different delivery and charging method. It is also about the ease of use and the streamlined way of “doing things”. And part of “doing things” is the way the environment is boarding new users and giving them the initial working environment.

So, what are the challenges for a SaaS vendor who is trying to move towards an automated activation process? And is this “automation” a panacea that every vendor should pursue? (Don’t be hasty and answer “yes”, because there is a catch to that…!). Let’s have a look at those challenges:

First of all it’s the sales process itself. In the traditional model, sales are accomplished by marketing actions, mailing lists, telephone contacts etc. When the application has a relatively wide scope, then sales calls, meetings and live demos are essential for the closing of the deal (Do you know anyone who has bought SAP or JD Edwards, just by browsing through their web site?) SaaS will challenge that! It is now possible to buy your SaaS subscription through a credit card, after having seen a live demo, a youtube video or in some cases after having a free trial period yourselves. That’s great, but how were these vendors able to provide you with a working environment, just seconds after your credit card or PayPal payment? Answer: They have invested in mechanisms that allow the environment to be “auto-generated” and populated with the very first and basic parameters that it needs to work. And these mechanisms simply do not exist in the traditional on-premise delivery model.

Then, it’s the start-up services and fees. After signing up and having a working environment, the customer may require some customization, some help with the parameterization, an expert opinion in some operational matters etc. The challenge for the vendor, here, is that the more expandable their application is, the more parametrical (and “plastic”) it is, the more options it gives to the end-user, the more complicated it is to setup. And this stands in direct opposition with the previous target of automated boarding of new users. It is a fine line between creating a wide-scope application and trying to keep it simple at the same time. Here is a good example: I had a look at a very well-known and successful SaaS Accounting product. I saw their customer file and found everything that you would expect from a typical customer record. So, as soon as you pay with your credit card, you are “ready to launch”. But what if that customer file needed to be expanded with new fields, additional validations and some design changes? Can this product do it? And if so, at what cost? And how fast? And will it require the provision of some “professional services”?

Another pain point in any migration (SaaS or no-SaaS) is the old data migration. Even if the product has been designed for immediate “embarkation”, you would probably be able to only do just a few things, if you didn’t have your old data, on-line. Imagine boarding a new sales system and not having your existing customer file; or an accounting system without your chart of accounts. The challenge here is that the SaaS environment should provide you with the tools for uploading critical data, by yourself. It must give you file layouts, examples and probably sample files to guide you through the process; ideally, without having to talk to any technical personnel of the vendor. Why is that a challenge? Because, typically, this process was usually undertaken by the vendor’s consultants or business analysts and in most cases they also performed a preliminary check of the files and they gave feedback on problems, as they came up. Now, the whole process must be executed by non-expert staff (that is you, the buyer) and all possible problems need to be reported before feeding false data inside the database. And I can tell you from experience that this can a pain in the… stomach!

There are more challenges on the endeavor of automating a SaaS environment and actually achieving “zero-effort” on boarding new users, which I shall comment on in my next post. Until then, all you SaaS architects need to remember that the application design and functionality is NOT the only wager!

Collaboration in SaaS environments (part 2)

2011-01-23T10:58:00.002+02:00

In the previous post we talked about collaboration capabilities that a SaaS platform offers to its end-users. The objective is to leverage two elementary SaaS facts: The fact that other users in that same platform share a common business model with you and that you share a common work space with others (not necessarily in your line of business).

In this post we shall discuss what are the tools that will enable collaboration among these users; be them of similar business models or not. I believe that these tools and methodologies remain powerful, regardless of the mission of the SaaS application itself. It could be a heavy-duty ERP application or a low-end sales CRM tool. The essence of the user comments, questions and “agonies” is still the same.

Chatting. I see a chatting tool very attractive in the sense that the user would be able to communicate with his/her colleagues inside the enterprise but also in the “community” or the “SaaS ecosystem”. Although there is no breakthrough in communicating with the in-house colleagues (if the enterprise believed that it should, it must have already deployed some kind of chatting tool), imagine the power of chatting with people outside your 4 walls and exchanging ideas on a variety of issues. You could be able to exchange ideas on business-specific issues and see how other people are doing it but also get instant help on the ecosystem-related questions, such as “how do I change my profile settings” etc.

email capabilities from within the application. In everyday life we send and receive emails, pertinent to our business and sometimes pertinent to a specific business transaction. For example, we ask our supervisor what to do with that pending invoice or how to go about that problem with contract number XYZ. There is a thread of emails that is exchanged between 2 or more people but this thread is never disclosed to a wider range of people. What if you wanted to update your subordinates about the final decision on the issue? You would then need to forward the email and you know how that is… tens of emails exchanged every day and sometimes we forget “this” or “that”. Now imagine, that discussion thread, relevant to invoice number XYZ, to be instantly attached ON that invoice. Every involved user would be notified as soon as they entered that specific transaction that “Action X must be done for problem Y”. So, corporate discussions and decisions are not spread around personal inboxes but are attached to the business transaction they concern.

Knowledge base. In a SaaS ecosystem there is a lot of knowledge “flying around” due to the fact that the number of users is far greater than any on-premise application and because users do not belong to the same enterprise. So, there are similar things that are done in a different way from different communities of people. What are the issues that have been discussed either in your specific business area or in the ecosystem? What are the possible solutions? Which solution is better? Your way or the other guy’s way? These are questions a knowledge base can provide answers to. A database of issues that is self-maintained by people with similar questions and examples. Why is Wikipedia so cool? Because people go there and share their knowledge of things. And this is a self-maintained database, so to speak. Now, imagine the same thing, but focused in your specific business area (or ecosystem). I believe that there a lot of applications on that area…

FAQ’s. In the same spirit, an FAQ section could prove invaluable. A section which would include ecosystem-related issues. If you are a SaaS provider, just think how many times you have been called on the hot-line support and have been asked the same trivial question over and over again: “how do I…?” An FAQ section would take burden of your hot-line and also assist users to find more quickly the answers they seek in those “trivial” questions.

Exchange of actual business transactions between companies. Imagine the possibilities if you and your vendor/customer reside in the same SaaS ecosystem. There is a variety of business transactions that you could do with them, with “zero pain”. Your customers could be given the authorization to post sales orders in your system. You could instantly receive vendors’ invoices as soon as they issue them. And have them posted in your database with zero effort. In an isolated system, we usually talk about interfaces and data exchange and seek to initiate a discussion between software providers, who then need to standardize an interface, test it and finally deploy it. In the SaaS ecosystem, these are possibilities that could be inherent to the application and you could be enjoying them with zero effort. The cost of such a solution could be included in the monthly fee that you already pay.
In fact, as a SaaS ecosystem is developing I see this as a major advantage of the SaaS offering as a whole. And a real business opportunity for the SaaS vendors, since they could offer such services right “out-of-the-box” and attract more and more users in their platform. Especially in cases where new revenue is generated from hearsay: A happy SaaS customer could suggest the platform to a co-operator with the final objective of gaining something for himself, too: The leverage of collaboration tools that are inherent in the SaaS platform!

From the above it becomes evident that a SaaS business application ecosystem can evolve to becoming a “social network”. It will surely be focused in users of similar business models as you and also users in the same ecosystem as you. It will never reach the heights of facebook but this is not the intention, anyway. The intention is to enhance collaboration in that micro-world that constitutes you SaaS ecosystem.

Collaboration in SaaS environments (part 1)

2011-01-02T11:07:00.002+02:00

First of all, I’d like to wish you Seasons Greetings and the Happiest New Year you’ve ever had. I will think of an even stronger wish for 2012, but this is too far in the future, so I may as well relax, for now!

A lot has been said and written about possibilities that a SaaS platform gives to the end-user, which a traditional on-premise model cannot provide. Today, I would like to focus on one specific issue that keeps me busy the last couple of weeks: collaboration. Let’s start with the fact that when you operate in a SaaS environment (let’s talk about multi-tenant, which is the generally accepted “best” model) you reside in one database with other users, beyond your own enterprise. What you share with them is one of the following two (or maybe both):

A common software platform and user-interface. We can safely assume that even if the modules that you are using are quite different from the other guy’s, the general rules of user interface, system rules, logging etc. are the same.

A similar or exact business model with your enterprise. e.g. imagine an accounting software for a small-sized enterprise – Most probably, the way you are doing it, is the way ”they” are doing it. Also, it is possible (although not a must) that the software that you are using is an industry solution for your lines of business. Therefore, a number of other, similar enterprises with yours are already operating in that SaaS.

The above two immediately ring the “Collaboration” bell in my head. There are things that you share with the other users, common practices, similar FAQ’s regarding the software and platform and business-related issues and how they are solved/tackled by this specific software. Let’s see some examples:

Common practices: I have an employee who wants to be a customer of my enterprise, too. Do I need two Person records for him/her. Or can one record cater for both activities?

FAQ’s: I have posted a transaction X and it’s giving me error Y. Where is the error? What can I do to fix it? The fix applies to all future transactions X, or just this one?

Business-related: I want to setup a transaction that will create a debit to a bank account. How do I do that?

Platform-related: How can I change my password expiry interval?

In a typical on-premise installation these questions are answered either by going back to the User’s Manual or the Administration Manual or, more often, by calling the I.T. department of the enterprise. But in a SaaS environment, there are a large number of users (in fact, there is an entire community!) that you can ask: the other tenants! And they can be hundreds or thousands and is it is possible that someone else has had the same question as you, before and it is quite probable that somebody else has found the best solution to the problem. Perhaps, that “best solution” has originated by the software vendor himself, who has identified users’ questions, classified them and studied the best way of tackling with the issue…

Therefore, it would be very efficient if the SaaS platform offered the possibility of collaboration and knowledge sharing between users, inside but also outside the enterprise. In the next post I shall describe a number of ways to achieve this. Till then you are all encouraged to use the good-old User’s Manual!

Mechanizing the new Enterprise

2010-12-19T18:06:00.001+02:00

In this era of Economic Crisis, things are dramatically changing inside the enterprise. Not only low-level employee headcount is decreasing but is some cases high-level, too. It is even possible that department merging takes place. For example typical HR processes are directed to the Accounting Dept. or Marketing is merged with Sales Dept., under one “roof” and management. This is a “business transformation” that needs to be supported by Information Technology, in new ways.

In a traditional organization, the HR dept. could have been executing their tasks using spreadsheets or even paper-based processes. This was a system that had been “developed” by an old fashioned HR manager (who is now close to his/her retirement and who will probably not be substituted due to downsizing). If a non-HR specialist is given these tasks, he/she will probably have a hard time finding his way around paper-based processes and custom spreadsheets. Therefore, the procurement of a new HR system is now a “must”.

Another example is this of the Sales Force Automation: The crisis is here, sales are going down and the sales process becomes more and more difficult. Mobile sales representatives must cover more mileage each day and the ordering process must become more efficient. So, the Sales Dept. must now get a “mobile or web-enabled sales system”, which salespersons will be able to access from their smart phones or laptops. (So device procurement is also an issue, here!)

Another example is the Production Planning. Now, it has to be further optimized and streamlined. Probably, that good-old “do-it-all” ERP is not good enough anymore. I also happen to know some production units that – due to special conditions and processes – are doing their production planning and resource scheduling with custom-made systems or spreadsheets. Maybe, now is the time for the purchase of a new specialized “production planning” module…

There are more examples but I think I made my point: In this era of economic crisis and “violent” business transformation, the usage of Information Technology is once again becoming a “hot” issue. Just like it started in the 80’s for the big enterprise and in the 90’s for the medium/small ones. But now it is no longer an issue of buying a big Accounting System or a do-it-all ERP. It’s all about filling the gaps that these systems leave behind. We are talking about new and specialized pieces of software (and hardware) that will support the transformation. HRIS for the HR dept, Sales Force Automation for the Sales Dept. etc.

These systems could (or must!) have the following characteristics:

Web enablement. The modern manager is more or less mobile. So he/she needs to have information available beyond the physical boundaries of his/her office. Also, in some cases the enterprise must “invite” its customers “in”. I have blogged about “customer self-service” in the past…

Cloud architecture. This ensures fast deployment, fast customization, best-of-breed functionality etc.; all the benefits that Software as a Service (“SaaS”) can provide.

Specific scope. You don’t deploy a big ERP (or a NEW big ERP) to do Sales Force Automation! You need specialized systems for a single piece of work. If you are in a small company, then the issue of all-around, do-it-all integrated system comes on the table, as I have described in my previous posts. But if you are a big enterprise, maybe you will have to take the cost of multiple systems and the project of integrating them…

Challenging SaaS (part 3)

2010-12-05T10:27:00.000+02:00

Anti-SaaS arguments can have their source in true technical concerns or (in some degree) by the buyer’s physical resistance to sign-in to something that they don’t own. This can become a critical factor in some parts of the world, where the sense of ownership is very strong (my country, Greece, is one of them; I hear it’s the same in India and I’m sure that there are a lot more examples like that). And this sense of ownership is strong in other aspects of everyday life, too. For example, the acceptance of leased car versus owning an automobile is not the same in all countries.
Let’s go on to see some more examples:

I want it up and running on Sundays. It is possible that what the vendor is providing “out-of-the-box” is hot-line customer support on working days and hours. Some prospects are challenging that by raising the argument that they do not just work “nine to five”. In cases like that it is only logical that you will be charged more if your require hot-line availability beyond the typical “9-5”. Let’s be honest. This is not a true “anti-SaaS” argument. Even in the case of on-premise, the IT dept. needs to employ an “after-hours” system operator to handle these exceptional cases. And this person is getting paid, too! And this person has to have a substitute in case of sickness or leave of absence! So, it is only logical that you will accept your vendor’s “extra charge”, to balance that cost that you will not carry, after all. In fact, we can – again – expect that this charge will be significantly lower since the vendor is using economies of scale.
This whole issue becomes tricky when the vendor is a global provider in multiple time zones: In that case, they need to deploy real 24/7 system operators and hot-line support for their global customers. Even in this case, I don’t think that system availability and after-hours support is a real anti-SaaS argument or a “threat” to the overall offering.

I need large-scale customization. I have blogged about this issue previously here http://tchristidis.blogspot.com/2010/02/customization-enemy-of-saas-part-1.html and here http://tchristidis.blogspot.com/2010/03/customization-enemy-of-saas-part-2.html. I will repeat myself but I want to say just this: If you’re looking at SaaS products to deploy, then you should also examine your list of customizations. Could they be just a little too exaggerated?

What technology are you using? It is a common question when your are trying to sell an on-premise piece of software. And this is only reasonable. The IT manager needs to understand the technology and see if its fits into their pool of expertise, their corporate policies etc. But when we are talking about SaaS, this is really not an issue. What do you care about technology, since it will be somebody else’s problem (the service provider’s)? In fact, if you are an IT manager that knows the basics of technology, you just need to get this information so that you can evaluate if something “terribly wrong” is going on with this SaaS product. For example, if they offered you a full ERP that runs in Visual Basic 5 and had MS Access for a database, then you could easily assume that this could not withstand the ERP volumes. But if they offered you a “Ticketing System” with max 2 concurrent users, then the system requirements could be significantly lower than the “monstrous” ERP. In any case, I find it difficult to believe that any SaaS product has something “terribly wrong”, in terms of technology, since one of the main concerns at its design stage was surely concurrency and a large number of users. Nobody is designing SaaS software for a max of 50 users, unless there is a clear target of single-tenancy modeling (which I doubt very much).

As a closing statement I would like to say this: There is a number of “anti-SaaS” arguments that prospects will raise and a significant percentage of them origins from lack of education around this issue. Another significant percentage comes from the threat that the IT manager sees in SaaS (for which I have blogged here http://tchristidis.blogspot.com/2010/03/is-saas-enemy-of-it-manager.html). In my opinion, it will take some more time of preaching and educating, but SaaS is definitely taking off. Some say that SaaS cannot replace “everything” (e.g. big ERP products etc.). Maybe this is true (for now). But as technology evolves and internet becomes more and more a commodity, this may significantly change in a few years…

Challenging SaaS (part 2)

2010-11-28T09:36:00.000+02:00

In this post I shall continue with the “anti-SaaS” arguments. In the previous post, we saw some arguments that are usually thrown to the table, from the first 5 minutes of discussion. If you get past these critical 5 minutes, then the discussion goes into more specific issues, such as the following:

What happens if Internet fails? Assuming that SaaS is a synonym to Internet Technology, this is the among the first (and funniest!) arguments that I have heard. Some people (say that they) recognize all positive aspects of SaaS but they are afraid of what’s going to happen if Internet fails. My usual answer is that “internet DOES NOT fail”. It is more probable that the electricity in your neighborhood is going to fail, than the Internet lines. And what do you do when electricity fails? You just stop working because your PCs are not working; the elevators in your building have stopped etc. Or, if you MUST work then you switch to manual: You issue invoices from your hand-written statement block and you process orders manually. That’s life!
I challenge all those people to tell me when was the last time that internet failed and they just don’t remember. Let’s face it: Internet is a commodity just like the running tap water and electricity. It is essential for everyday (corporate) lives and we cannot design our policies around the possibility that “internet may fail”.

Our corporate policy refuses SaaS architecture. General corporate rules may refuse or discourage the adoption of SaaS architecture and/or offerings. The main concerns are a) the actual location of the data and who has access to them, b) general security architecture guidelines and requirements that the Enterprise believes cannot be met by the vendor. The first problem of where the data actually resides has been answered in the previous post. Regarding the second issue of architecture guidelines, we have first to make this remark: it is not unusual that a SaaS vendor overbalances the customer’s requirements, simply because the vendor has “done it before”. In any case, the vendor should be in a position to accept security reviews, apart from offering a “good” SLA. This may even come down to actual Data Center review on behalf of the customer’s security team. Now, maybe, all these sound a little too much for lightweight applications that tend to sell directly to internet customer. But when we are talking about medium-large enterprises, then it becomes a real consideration.

We are OK with the data being stored in the cloud, but we need local backups, on demand. In my opinion, there is no reason for this request. If the SLA covers the backup issue (which, obviously, it does) then the enterprise does not need local backups. Even in the event of contract termination the customer can surely expect that their data will be delivered to them in a readable format. But again the vendor must have a ready answer: either their systems offer this on-demand local backing up by the end-user or they provide this service upon request.

We need to deploy our own Reporting and Business Intelligence tools. OK, now it gets tricky! This customer wants to buy SaaS but they want to apply their existing BI methods and tools on that Cloud Software. Not very probable! Unless these systems offer some out-of-the-box functionality for plugging-in. Or if the vendor has already integrated with some of the famous BI and reporting tools. In any case, I think that this is just wishful thinking: you can’t expect that you’ll change your “heavy-duty ERP” with a new SaaS offering, but still be able to use the good-old same reporting system. It’s like changing your car with something new and advanced but insisting on using that old steering wheel! Sure, it worked fine, but it doesn’t fit to your new car!

More to come on the next (and last) part of this blog sequel.

Challenging SaaS - Part 1

2010-11-21T11:07:00.000+02:00

In my efforts to sell SaaS I have been presented with a number of “anti-SaaS” arguments. Some of them are just irritating but some of them require a professional and comprehensive response.
In this post I will try and enumerate these arguments and also provide a convincing response. You see, I believe that adopting SaaS is also an issue of people (customers) training. They still do not understand the benefits of SaaS but they clearly see its drawbacks, from the first minute of discussion. A few days ago, an accounting professional responded to me like this: My personal mentality drives me to always own what I am using. That’s why I don’t embrace the idea of SaaS. This person clearly understood the economic benefits of SaaS, but he still resists to adopting it.

Where is my data? People tend to think of data as something “sacred” – and it probably is. Enterprise data is the enterprise’s asset. They have worked long and hard to create this clientele (i.e. customer file) and those economic figures (i.e. accounting database) and they are not prepared to just deliver this to a third party. Of course, the SaaS provider must provide SLA’s and confidentiality terms and conditions, maybe even penal clauses in case of data leakage. But what the average customer thinks is “if my data leaks out, who cares about penal clauses etc. I will have LOST my data”. Which is correct, no doubt about that. At this point the SaaS provider must demonstrate seriousness in their SaaS offering and start building up their reputation from day one. The probable “problem” will always be there, but the customer must also recognize that they don’t need their servers to be placed outside their physical four walls. Data leakage can also happen from within the organization. Bottom line is this: SaaS presents fewer dangers in data leakage simply because the SaaS vendor has much more to lose in case of misusing the data, compared to the average employee that can just resign on a Monday morning.

SaaS is too expensive. Usually, when the vendor presents his pricing model, the customer makes some quick multiplications like this:
[users] x [months] x [monthly fee] = [WOW! WHAT THE HECK IS THIS?]
All SaaS vendors know that this is not correct. It is not just about one simple multiplication. One must put down all related numbers and see the Total Cost of Ownership. Also, take into account the initial investment on licenses and hardware that SaaS does NOT require. And finally, the HR cost (personnel etc.).
One way to go about this problem is that the SaaS vendor, in the pre-sales stage makes a thorough presentation of such matters. In this presentation, the Financial Director of the customer must also be present. The trick is to drive customer’s brain away from the “simple multiplication” mode.

SaaS is too cheap to be true. In some cases, the above multiplication produces really low numbers! (for example, in cases of low-end applications or limited-scope technical tools) Then customers tend to believe that there is a secret “catch” in the deal (“Oh dear, it can’t be that cheap!”). Instead, they should simply take into account the fact that the SaaS vendor is doing what they’re doing for a large number of customers and users, so the vendor is using economies of scale to offer such low prices! Additionally, if we are talking about a limited-scope system or tool or software, then this is offered “out-of-the-box” and so the maintenance and customization costs are close to zero. This is not the case with, say, a big ERP.

That’s all for today, I will come back on this issue, with more “deal-breakers” that potential customers raise on the pre-sales stage.

SaaS and the Outsourcing function

2010-10-23T20:28:00.001+03:00

SaaS is not a brand new idea. It used to be called “ASP – Application Service Provisioning”. It didn’t work out very well back in the 90’s and 00’s, but now it’s back. There’s no doubt about that.
Neither Outsourcing is a new idea. It has been going on for quite some time now.
In this post I am going to explore what can happen when these two services are mixed. What business opportunities can be born for both the outsourcer and the SaaS provider, but most of all what are the benefits that the end-customer will enjoy.

First, let’s try to answer the basic question: Why do we need to mix these two services? The answer is that outsourcing will surely need some kind of “tool” to deliver what it is promising. And on the flipside, a SaaS provider tends to be somewhat “technical”. They cannot always address the real business issues of the potential client. And they surely cannot offer anything more than their software and maybe some consulting and best practices on the usage of this software (exceptions to that rule, I apologize!).

A very common outsourcing function is this of the Accounting & Financial Services. A lot of SME’s (but also bigger enterprises that have good reason to do it) outsource this function to consultants (or even small accounting firms). Another function that is commonly outsourced is the HR. This includes the management of “trivial” issues such as regulatory reporting, leaves of absence etc. but also more complex issues such as department staffing, training cycles and management, downsizing etc. The service providers will need some kind of tool to perform these tasks; and what better tool to use than a SaaS offering! Using the client’s existing systems may be difficult (the outsourcer needs to learn the millionth system; a system that they may use only for this specific customer – and this is a cost consideration) or even impossible (e.g. the customer does not have an HR system). The usage of SaaS systems offers the following advantages:

The outsourcer uses a piece of software that they already know and probably have ready-to-go.

The outsourcer need not learn new systems or become a part of the client’s existing security system and procedures.

The client can feel confident that the outsourcer will “jump on the horse” immediately and start doing his job, without any learning curves.

The outsourcer probably has (or can develop) a long-lasting relationship with the SaaS provider, so that bug fixing is instant and new releases are fast and correctly designed and implemented. When the SaaS provider needs to build new functionality, he need not “re-discover the wheel”. He has a close co-operator as an ally, who is able to actively contribute to this effort.

The customer instantly enjoys the fruits of this co-operation.

In fact, this last point should make outsourcing companies turn their heads to SaaS and vice versa. It is now clear that these two functions can complement each other, thus creating strong, integrated services. In this effort, I see the outsourcer to play the first role (to go and get the job). The SaaS provider will operate in the background as the outsourcer’s “IT department” and advisor.
This combination can create strong synergies for small/medium consultants, outsourcers and SaaS providers and open new opportunities. Is anybody interested?!

Business Intelligence in SaaS offerings

2010-10-09T13:24:00.001+03:00

In this post I will try to explore the challenges that one will face when they try to mix or attach Business intelligence (BI) tools in their SaaS offering. In the traditional software delivery method, you had your database installed on an owned server. You just had to give access to users and designers (through their BI desktops) to access these data. They could query and download data (given certain permissions, of course, but this is another story).

In a SaaS application, the database no longer resides in your premises. If we are talking about a private cloud, then, yes, between your desktop and the database there is the internet (“wild” internet or VPN). Your BI application should be able to access a remote database server through TCPIP (which is obviously not a problem for modern applications).

But, what if you are a user of public cloud – multi-tenant system? Let’s see some points of consideration:

True multitenant systems comprise of one database instance and one application instance. The “Chinese walls” that the SaaS vendor (must) has built, are engineered on the application layer and/or on the database layer. Typically, on the application level, one must take care that user A can search entries performed for “company A1” and user B can do the same for “company B1”. Probably, a system administrator would have access to all “companies”. On the database level, one option is the row-level security that some databases offer: A user may do a query like this: “SELECT * FROM MyTable” but the system will not reply with ALL rows of this table; just the ones that belong to the particular user.

It is possible that your BI application (or your users) may require large volumes of data in an ad-hoc basis. They probably need complex calculations, summarizing values, digging into history data etc. These processes can be quite heavy for your system. It is very common (and actually a best practice) to have your BI tools accessing a database other than the “production” database. You may call it a “reporting-dedicated environment”, a “data warehouse”, a “data mart” or whatever. But surely, you don’t have your end-of-month statistics reports running on the same database in which sales orders are processed! Typically, you achieve this by internal development: you form a project through which data structures or sets are designed, then your programmers take care that these data sets are populated and then BI reports are built on these data structures. And this is usually a custom-made environment/database schema. What do you do when you switch to a new SaaS application? How can you run complex reports and calculations in the middle of the day, while a thousand other people are doing their every-day tasks? One solution to this problem is that your vendor is also providing you with a duplicate environment (not customized, though), where you (and others) can run your BI stuff. This will surely take the load off the “production” database, but it does not solve the problem of the customizing of the data sets. Are we looking at a project-based custom development that you will ask from your SaaS vendor? Or maybe a function that will export your SaaS-based data to a local database? Take your pick!

On a more practical issue, let’s suppose that all these technicalities have been solved. You have selected your BI vendor and your SaaS-business-application vendor. There is the possibility that after having selected your SaaS vendor (because their application has all the features and functionality that you require), you find out that their database structure does not cater for all your “personalized” reporting needs. For example, you would like to categorize your SKU’s in the Items Master File in a three-level categorization tree, for statistics purposes. What do you do when you find out that the application does not have this kind of categorization? Or you would like to apply special discounts on the lowest level, but the application supports special discounts on the higher level, only… I’m trying to make this point: when you are in the software selection process, you not only need to see if the software provides all the “transactions” that you want but also design your reporting needs and have them “tested” against the out-of-the-box offering.

Tenancy models in SaaS

2010-09-16T20:08:00.001+03:00

Anybody who works or talks around Software as a Service (SaaS) has dealt (or, at least, come in contact) with the question “multi-tenant or single-tenant environment”. This question has become so common that one might think that there are just these two options. I would like to scrutinize on this issue: What alternatives are there when designing a SaaS environment, in terms of tenancy?

Single-tenancy With this model the supplier sets up one complete environment for the client to use. By environment, I mean the application server, the database server and any other component that the application needs in order to be operational; excluding, of course, the network and some common network devices, firewalls etc. With this model, you have 10 servers with 10 OS’es, 10 application instances, 10 databases. You also have 1 rack (with a limited physical capacity, of course) and you are bound to set up the 2nd one, pretty soon!

Single-tenancy, virtualized With this model the general architecture is the same as before, with the one very important difference that each new “environment” is not comprised of new servers. On the contrary, new servers are “created” with virtualization of the first one. With this model, you have 1 server with 1 OS, 10 application instances, 10 databases (plus the virtualization software).

Multi-tenant In that model the “application infrastructure” is unique. You have 1 application instance with 1 database, residing in 1 server. In these cases, the “1” is not usually true, since these environments are used to serve a larger number of users, and so although logically there is “1” server, physically we may talk about an array of servers, a cluster of databases etc. In general, though, these technicalities do not concern the end-user (except for the part of high availability and disaster recovery, which is another issue…). Anyway, in this model, since the database is common, the data of the various on-board customers are separated “logically” by application entities, such as “Company Code”, “Operational Unit” etc. Modern databases also offer a record-level authority, which is a significant feature.

Shared-tenant I don’t think that this is a widely used term but I will define it like this: It is a multi-tenant environment, in which some (not all) application entities are shared between tenants. Tenants (customers) are obviously using their “personal” data (such as user names, sales documents, accounting entries, customer file etc.) but share a number of other entities that they have agreed upon with the other tenants (for example the Car record in a closed or syndicated dealer network, a list of loan products that a bank is offering to that same network or a knowledge database in a community of accounting professionals). In this “hybrid” solution you must want to get on-board, but also the others must allow you to enter, or some “higher authority” decides who gets in (such as the network owner). Therefore, this is an environment where probably users know each other. From the technical point-of-view this is a multi-tenant environment with some database entities that allow common access by everybody. You could achieve the same thing with single-tenant installations that replicate a part of their database to each other. I am pretty sure, though, that this would be a “replication nightmare”.

Shared Hardware In this model, the tenants are using the same hardware but their application environments are fully detached from each other, since each one has his own instance of the application and the database. In these cases, database design (schema) and application code can be replicated – if need be – across instances, so that everybody has an exact image of the application structure in his hands. Or maybe not, because each one wishes to have his own, customized version of the software (It is in the vendor’s discretion to allow or disallow such sharing).

I hope that the above list is close to complete. In one of next posts I will talk about pros and cons of each solution. Till then, keep “SaaS-ing” !

Customer self-service (the solution)

2010-09-03T09:19:00.001+03:00

Having seen “the problem” of shifting tasks from inside the enterprise, to your co-operators, today I will propose “the solution”.

The basic idea is to let these co-operators become part of your organization. Let them “in”. Let them become users of your application systems. Let them pull the information that they need instead of you working to push it to them.

e-Business started with the basic idea a long time ago. And so, electronic shops were created. You can now go “inside” a million shops, browse through the products, order them, pay on-line and get on-time notifications about the status of your order. That was a real breakthrough. But it is not enough, because it stops that the final stage of the order. I think that we must have agreed so far that Sales is not the only function that your business is performing, right?

How do you manage to give functionality to your co-operator, before the Sales Order and after that? Through a web portal that goes beyond the logic of the e-shop. There, I said it: web presence and e-shop are no longer enough. You have to reach out to your co-operators with new ways and services. Hence my title: “Customer self-service”. Systems, portal or web services that enable the co-operator to perform actions inside your application systems. These actions are targeted to give them some value while at the same time reducing the time that you consume with trivial tasks with them. So, they are servicing themselves through your systems.

Actually, the idea is not new. It is just not as grown in the minds of people as the e-shops. Remember what your bank is doing? It is called web-banking and it is exactly the same: They have opened traditional functions of the bank teller (and much more) to the web, so that you may use it, without the presence of the bank employee. It is faster, easier and cost-saving for the bank. This is exactly what I propose for your SMB and, no, it will not cost the Gross National Product of a small country to do it. What I have in mind is a new module of the web system that the enterprise is currently operating: On the same system that you keep you Accounting, Inventories, Customer balances, you could build a “secure area” where co-operators can enter and execute some of the functions that I described in my previous post.

Of course, possible solutions vary depending on whether you already have deployed an internet business application for your core functions:

If you have, then you already have the infrastructure to go “on-line”. If your application is scalable enough, then it may be a matter of weeks before you implement such “customer self-services”. On the other hand, it always depends, on whether the “programmer” is you or an outside vendor, such a traditional software house etc. In these cases (which are obviously the majority) things can get tough; simply because most traditional software houses do not share the above ideas of an open system. Most probably, if you ask them to create something from scratch, it will cost you a lot of money because it’s going to be built as “custom development”. On top, you should also consider that, being a custom development, it will not be part of their standard release planning, so future enhancements that you’ll need, will cost you more than expected.

If you haven’t, then you should start thinking about infrastructure, new servers, system software and possible personnel to handle all these things. Then, it is the software itself. Will you develop it or will you turn to an expert? If you are an SMB, then the answer is easy… An alternative to that is to turn your sights to somebody who specializes in this kind of development or maybe even a SaaS provider: You will get your “customer self-service” system with no initial costs, just a monthly “rental”. Of course, you will have to create interfaces from your back-office system to the new one. This can be a hassle, but a necessary one.

Regarding security and performance, there are quite a few tricky points: Although a hypothetical system may provide the required functionality, is it correct to “board” external users to your internal infrastructure? If your business runs on web server XYZ, is it correct to activate external users to that same server (moreover, is it possible to do so)? Also, what happens if your “visitors” become large in number? Will they seriously affect the performance of your core business application? And the data that they will be querying are going to be pulled out of the corporate database or a “light copy” of it? In the latter case, will it be on-line? Perhaps it is more logical to deploy that “customer self-service” system in a new environment and probably another platform? If so, what will happen with the total cost of the solution?

…or, you can do something else: Deploy a new system, such as E-ON’s “Retail Internet eXchange”, which is a purely web system, servicing a large part of today’s SMB, such as inventory management, accounting & financials, CRM etc., offered through SaaS for some Euros per month AND with its own “customer-self service” module.

Anyway you see it, implementing “self-service” functions will drive you to what I call “the next step in systems evolution”. By now, it has become evident that a closed system will serve you well but its scope will always be limited to your company’s physical four walls. So, be sure to board that train and implement self-services!

Customer self-service (the problem)

2010-07-30T12:56:00.001+03:00

A lot of discussion is being done about CRM. It’s been going on for quite some time now. These days, with the blooming of social networks and the millions of users that they attract, a new discussion has been opened, about Social CRM.

Don’t get me wrong, but I believe that some of the aspects of SCRM are somehow “exotic” for the average SMB. Let’s not forget that some of them don’t even know what CRM is or they have placed it low on their priorities! I know this because I have conducted my own research on the matter. Don’t get me wrong: I could go on and on about the benefits of CRM and SCRM, even for the SMB (let alone the big enterprises), as a large number of other bloggers have already done, but this is not my purpose today.

If we accept the basic definition that “CRM is a tool and a methodology to help the Business create and further grow relationships with its Customers”, I would like to propose another way of doing this (building and growing). I want to tell you right from the start that this will not replace the CRM “virtues”; it will work side by side with it. Let’s go:

In a typical CRM or SCRM situation, you’ve got users working with the system to register prospects, customers, leads, “to-do” actions, problem tickets etc. These are examples of functions that YOU are doing. Imagine a “toolkit” that is offered to YOUR customers to let them work with you or for you. I am sure that you can find a number of customer-related functions that you are doing everyday, which are part of your business, yes, but you would very much like to “throw away”. I am also sure that such functions exist not only for your customers, but for other kinds of co-operators, too, such as suppliers etc. I can imagine some examples:

A supplier calls your Accounting Dept. and asks for his current balance. An employee of yours is working on the Accounting system, looks at the balance. Then, he probably prints a statement, puts it an envelope etc, etc.

A customer calls your Sales Dept. to make a query regarding one of your products. (No, you are a typical SMB and your web site is not well-organized and not on-line with your ERP. You don’t have on-line inventory, because you thought that you could do e-business with 1.000 € of cost and a university student for a developer – I will blog on that another time…)

The above customer wants to receive a “statement of account”. He is a regular customer, with weeks of credit and open balances and frequent orders. He may be calling you two or three times a week, or more…

Another customer wants to give you feedback that they didn’t find what they are looking for in your inventory. Sure, they could do it through email, in the usual unformatted and unorganized way. And you would rely on a low-end employee to receive and process the request on his personal email… Wouldn’t you like to have an “inventory” of such “new requests”, inside you application systems?

Your business is doing good and you issue a large number of invoices. Instead of printing and sending (and consuming time and paper for it) why not “transmitting” them electronically, somehow; and I don’t mean emailing them… (Note to Greek accountants and lawyers: please do not bombard me with the usual “this can’t be done” etc. etc. It CAN be done, period).

You are a service provider of some kind and you want to organize your work through appointments. Typically, your customers call on your call-center. Therefore you need a call center which is constantly growing as your business grows. What if they could book an appointment from the web? What if the system could check and acknowledge the time and date? What if it were able to send SMS notifications one day before? What if...?

The above are only a few examples of actions and tasks that YOU are currently doing, but I think, could be shifted to your co-operators. Therefore, while CRM is perceived as “exotic” and time-consuming by some line-managers, I am sure that they will appreciate ways that workload is taken off of the shoulders of the employee and moved outside the enterprise. Today, I described the problem. Stay tuned to find out the solution.

Personalization in web applications (part 2)

2010-07-09T09:50:00.000+03:00

In this 2nd post which is dedicated to Personalization, I shall continue to list some features that I think are interesting and welcome by all users. I am sure that you will find “yourselves” in there (if you are web developers) or that you will see a wish-list (if you are internet users).
Remember, the object of Personalization is to make the web system more attractive and more usable at the same time. After all, with all these systems and sites out there, you have to make a difference if you want the users to stick to your system, instead of the next guy’s.

Save Searches
All web systems provide some kind of search facility, be it a generic search engine that looks inside the web site and returns relevant documents or be it a search facility for the supported entities of that web system, such as “invoice search”, “loan search”, “customer search” etc.
I would bet that a user friendly search offers a whole bunch of search criteria. I would also bet that having an exhaustive list of search criteria can be overkilling for those of you that are used to work with these search engines in one (or two) specific way. For example, an accounting employee usually needs a “search customer by name” function. Nothing else. Who cares if the search engine also provides the city of residence as an additional criterion!
The mistake that a lot of developers do is that they overwhelm the user with a bunch of features and thus they achieve a level of complexity that is not welcome by some… On the other hand – yes, you are right – you just can’t have a “dummy” search with just a couple of obvious fields.
What do you do? You give the ability to the end user to save their searches. That way, low-end users will be able to just click on their saved search and the system will automatically pop-up their favorite or most common search criteria list.
Let alone the fact that you could have a fast path to “all my saved searches”. So you can present to the user all of their most-commonly used searches, in just a click. Simple, yet invaluable!

My personal settings
The more parametrical a system is, the more clicks and selections it will require by the user. This is perfectly understandable by you and me, but – make no mistake – the end user simply does not understand why they have to execute 15 clicks to issue a cash receipt of 15 dollars!
The name of the game is “defaults”. You should equip you system with default values for some very critical functions. Default values that can be changed by the end-user with just a click. A classical example is that of an accounting employee who – in the morning – is posting tens of accounting entries from bank statements and when they’re done with it, they start to register supplier invoices. The “bank statement” document and the “supplier invoice” document should appear automatically to them, by their selection. Imagine that for X number of documents they save exactly X clicks! A huge benefit. And your system is probably executing X less screen refreshes of the web browser. That’s… more benefit!

Customization of literals
I’m sure that you’ve seen this before. One of your customers does not like the term “status: invoiced” and they would prefer “status: closed”. The next customer argues that “closed” means something bad and they would prefer “status: completed”. And, on top, they say “why is it so hard to change just a small word? Will it take you more than 3 seconds to do it?”. There you have it: a “simple” request which you can’t serve and thus you are becoming the cumbersome and “stick-to-your-own-ways” IT guy.
But seriously, you should consider creating a glossary of terms widely used in your system. Then, a user (or better a group of users, say those working in the same organization or company) can agree that “invoiced” can be changed to “completed”.
This is the kind of argument that a user would not raise back in the days of monstrous ERP’s of the 80’s, but in today’s world of www and SaaS, they do have increased requirements, even on the wording issue.

Customization of frequent and critical transactions
Have you ever seen two users that imagine the customer file structure the same way? No? Me neither! Everybody wants the screen to show different data, to hide and show fields as they wish, even to alter validation rules from one user to another.
I recently had a customer that said “the correct layout of the fields is not last-name-first but first-name-first”. Yep, I was forced to customize the customer form to show fields “the other way around” (and I did it parametrically because I didn’t want my other SaaS users to see any difference on their layout).
Therefore you need to be able to customize your screens as per the user’s requirements. Again, an accounting user cannot see why they have to enter the customer’s email, while the marketing user can’t imagine a complete customer record without it! This should ring a bell for you: optional field for the one and mandatory for the other…

Scheduled tasks
It is probable that your system has some scheduled tasks that usually run over night. I don’t mean system-related tasks, such as database purge and reorganize. These are obviously controlled by you (the administrator).
I’m talking about application-level tasks that affect the end user: A log report, daily activity report, a warehouse balances update batch process etc. For tasks like these you should provide the user the ability to make their own schedule, since they know best their time windows.
Of course, your system might also have some down-time requirements, per day, per week or otherwise. So, giving the user the possibility to schedule their tasks can be somewhat tricky. Still, it is a necessity…

Anyway, this concludes my series of “personalization of web applications”. I hope that you found it interesting and that it gave you some food for thought. I would also like to hear your ideas on the issue, since – I’m sure – you have faced even more challenges.

Personalization in web applications (part 1)

2010-06-18T17:16:00.001+03:00

In this era of “www” domination, more and more software vendors turn their sights to web application development. You can see traditional client/server (or even COBOL!) developers, turn to modern development tools, such as Microsoft-based, IBM-based, Open Source, you name it.

All of them are willing to invest on re-building their traditional applications and re-launching them either with the same name (“web version now available”) or as a whole new product offering.

Web technology, HTML, Javascript etc. offer new possibilities and functionality to building modern applications with “sharp” user interface and new tools for the end-user to exploit. In this post, I would like to focus on the issue of “personalization”. This is a term that did not exist when the ERP’s of the 80’s were dominant. So, what does “personalization” mean in a modern day web application? What are the features and what are the benefits that you get from these features? Don´t get me wrong; I am not aiming in presenting an exhaustive list of features; I just aim to point some things that some of us are already accustomed to (but not realizing it) and give some “push forward” to the ones that are just starting to look into the “personalization” issue.

Look’n’feel. Color schemes, logos, fonts etc.
If you think hard enough you will find that there is a quite big list of things that you could do in order to provide personalization capabilities to the end user. Color schemes are a nice example: When an error occurs, you usually pop up a red error message, because red is the color that draws attention. Recently, though, I had a customer of mine saying “what is this red thing up there? Make it purple. Red is a very offensive color selection”. This guy had a clear view that the error messages should not appear so damn irritating to the end-users. It’s like yelling at them!
Put simple, I would like to be given the option to change my color schemes, depending on my mood of the minute. I must be given the opportunity to put my company’s logo at the web form, even if I’m working on a multi-tenant SaaS system. And that “Times Roman” font? I hate it!

Customization of menus
I am sure that you (software developer) have thought very hard on how your application’s menus should be structured. But there is one thing that you don’t know, for sure. And this is my job. I have specific tasks to complete, executed in a specific order. When a problem arises I have a check list to follow and resolve the issue. And for that (and many more reasons) I would like to be given the opportunity to build my own menus. I’d like to have “new customer” and “new ticket” in my CRM, side by side.
Therefore, ability to customize menus and also include “fast paths” to some critical clicks is a nice feature.
Also, ability to preselect some options for myself is also a time-saver. If I operate in a cashier position, I use the “payment receipt” more often than anything else. So, prompt me this option as a default selection and save me some clicks…

Customization of workflows
Any business transaction includes a number (larger or smaller) of workflow steps. Modern perception of a business transaction is that one is not completed by its own self; a series of things must happen in order to complete a business transaction. Take for example the approval of a leave-of-absence: It is not enough to “enter” an absence application; it has to be pre-approved by your supervisor and then approved by your manager... I am sure that your company does not approve leaves of absence the same way that mine does… Therefore, a workflow must be customizable by the user. This is a statement that is often self-evident (take for example the loan application for a Banking institution. You cannot talk about an application system, if you don’t have a customizable workflow), but not always. You can find a number of business transactions that have been broken down to small pieces and nowadays they have been standardized (like, say, a warehouse purchase order). So, you may find a number of software packages that offer the “purchasing workflow” right out of the box. Still, again, in my humble opinion, there is no such thing as a workflow “written in stone”. There will always be a new case or an exception to the rule.

Recent visits and “fast path” menu
It is very probable that a user executes a large number of transactions every day. It is also logical to assume that he enters some “screens” of the system more often than others. If the business application that they are using is quite extensive, with lots of menus, clicks, icons etc. then it is probable that this “busy bee” is lost somewhere in the middle. I can say this for myself: I build applications for quite some time now and I always grant myself all authorities. I execute complex test scenarios and after a while I find myself lost in the series of actions that I executed. But in a web-based system, “all” actions are being done through web pages. Therefore, I would love to have a log of pages that I’ve recently visited. I didn’t have it (so I built it!).
A recent visits log can also be of great use to new, inexperienced users. If they lose their “way home”, they can use this feature to get back in track.
Let alone the fact that it can also serve as a tool for the Support Team to track a user’s path, in case of error handling or bug reporting…
A variant of that it the “fast path menu”, which is not a brand new idea. Older applications had a feature like this. It is also very common in web-banking applications. And it is always welcome. You will find it (usually at the top-right corner of the page!).

All of the above are features that will add points to your applications and to the end-user’s experience. Stay tuned for more examples and ideas, in the next post.

Economic Crisis - How can I.T. help

2010-06-05T10:58:00.001+03:00

Amidst an environment of Economic Crisis (global or Greek!), the modern Enterprise faces a number of challenges. It also faces some pressing questions about its mission and objectives: should it turn its sights to new ventures? How is its mission statement affected by the crisis? What are the alternative revenue sources that can be used to enhance the financial position of it?

In this post I shall not deal with such issues (which are mainly in the agenda of the CEO or the President). Instead, I shall focus on “trivial” problems that the Enterprise faces in its everyday operation (ones that are amplified, though, in an Economic Crisis situation) and how Information Technology can assist in tackling them. In the end, I intend to show that I.T. must be utilized (“mobilized”, if you will) in a time of Crisis and that I.T. is a valuable ally in the “war against the Crisis”. I will approach this goal by identifying some of the problems that are enhanced during an Economic Crisis Situation.

The Crisis hits your customers, too
In a time of crisis you are not the only one that is affected. Your customers are, too. And this has a direct impact on your revenue. Do you know which are the customers with an open balance? Yeah, sure, you have that old-fashioned “customer balance” report. But I bet that it can’t provide you with qualitative information like: how old are these balances? How often customer A leaves an open balance of X dollars for Y days? Have you ever contacted them to close these balances? When? Who? What was the outcome of those contacts?
Also, is your infrastructure (software, accounting, automated email systems, CRM, you name it) giving you “early warning” buzzes for those problematic cases?
And which employee has undertaken the task of communicating with each of these customers? When?
The list goes on and on…

Minimize your warehouse inventory
This is a lesson that any and every warehouse manager knows. Still, I bet that there a lot of you out there with warehouse systems that do not help in that direction. In fact, I know that there are a lot of you that have warehouse accounting systems (balance tracking, price lists, ordering subsystems etc.) – and they work fine – but don’t have a WMS (Warehouse Management System) and don’t apply forecasting algorithms for the replenishment of your warehouse.
So, how can you reach the goal of minimizing your warehouse inventory, if you are managing some thousands of warehouse codes, with your brain?...

Expanding you customer base
If your customers face economic problems, then now is the most pressing time for you to seek new customers. If you achieve this, then you should go through the crisis “tunnel”, almost untouched.
How is your current I.T. infrastructure helping you identify your best selling products? Yeah, right, this is a standard report in the Sales Module of your ERP. OK, but what products sell to which customer profile. Do you actually maintain customer profiles in your marketing department? And how are they mapped to actual product sales?

Maintain and increasing customer loyalty
It is very probable that prices will go down in your product range because you and every competitor of yours are being pressed. So, your customers will grab the opportunity and make new market research for themselves, to find lower prices. When not in an Economic Crisis situation, customer loyalty is – by definition – higher. The market is stabilized, prices and relationships are too. It is in a crisis situation that almost all customers will initiate a new cycle of market research. How do you keep your existing customers?
Does your system allow you to create and maintain discount campaigns?
Have you deployed Predictive Analytics to identify which customers are most likely to leave you? For what reason? How do you tackle these cases? How can you make a direct emailing campaign? Does your 90’s ERP support such functions? Do you own a CRM system?

Increase customer service
In order to keep the customer happy, it is not enough to offer the lowest selling price. Customer will also appreciate some more distinguishing “virtues” that you display. And one of them is Customer Service.
When a customer comes in, do you recognize them immediately? Do you have a complete image of his personal data? More important, do you have a complete image of the previous transactions that you have done with them? And what about issues and problem tickets? Have you registered them? Do you know that they were satisfied at the end? These are issues that your traditional accounting system (or even ERP) cannot help you with. You need something more. Call it CRM, Data warehouse, Customer Base, Document Management, whatever.
Imagine that you were a customer and walked in a shop and a smiling employee immediately approached you and said:
- Hello, Mr. Smith, how is your new SUV 3.0 GTX running? And what about that gorgeous BLUE color?
- Hello, Mr. Smith, how’s your wife and child doing. It’s been 3 months since we last talked on the phone? And I know that the problem you had was solved by our certified technicians.
Hello, Mr. Smith, thanks for stopping by. I saw that you responded to our recent email campaign. I guess that you came over to see our new product line, right?
All of the above intense-font words, are data pulled through the system when you punched in “Last Name: Smith”.

Budgeting and forecasting
Do you have a budgeting and forecasting system? Let me rephrase: do you actually know the impact of the Crisis to your business so far? Do you have any idea of what is going to happen until the Crisis is over? (Some say “it’s going to get uglier before it becomes prettier”)

I think that the above is just a small collection of urgent issues that the “line” manager must face in a time of Economic Crisis. And to do that, they need extra support from their I.T. resources. I think that I have proved that and I hope I have also proved that the information cannot be delivered to the manager just by printed “reports”. But more on that, in a future post. Until, then, go on and identify the most pressing issues of your department. Take them to the CEO and the CIO and see what happens…

CRM, integrated with your core-business software

2010-05-21T10:24:00.001+03:00

In this post I would like to tackle an issue that has often become a point of dispute between different “schools of thought”: Do you need your CRM module, integrated with your core-business-function software, or not? How does an integrated CRM module help you (better) than a separate system?
First, we need to remember that (most will agree) CRM is not “this” or “that”. Every operation or enterprise has its own needs and requirements. Everybody is looking at their customers in a different way: Somebody may be particularly interested in the accounting balances and early warning on high ones. Another may be interested in Ticket/Problem handling. A services company might be interested in keeping time records per customer per project. The examples are endless. For that, I will try to provide general answers that have (I hope!) global applicability.

Firstly, I will acknowledge that separate CRM products will often offer more functionality (since that software vendor specializes in the CRM area). But there are some issues that a separate software cannot solve. Here goes:

Customer-centric software
We can safely assume that any software that includes some form of CRM includes (at least) a central customer database. This is essential not only for your CRM functions but also for your sales and/or back-office operations, whatever they might be. I have seen traditional systems (yes, older, but still functional) that do not have a central “Persons” repository. Or if they have, they do not protect the user from creating multiple entries for one “Person”. This will be a “CRM nightmare”.
Therefore, a system with an integrated CRM module will most likely have a central customer database.

Customer file accuracy
If your CRM is not integrated with your core-business software, then, by definition, you will have at least two (2) customer files in your organization. This will obviously add more work for the maintenance and synchronization of these two files. A few years ago, I have worked in a project where the enterprise had 8 customer files! And they tried to compile them in one “CRM-targeting” file.
Also, we must not forget another angle of the same issue: Different customer files may have different available fields. Sure, all files will contain name and surname, but what about date of birth, number of children, education etc. Here are some examples:
1) If you are a bank and you need to cross-sell new products to existing customers, you need this information on your core-business software and not on your CRM.
2) If you are a car dealer, you need to know when the last visit of the customer in your workshop was, in order to produce a mail list for “I haven’t seen you for a long time” customers.

Work on the same “desktop”
You will increase productivity if you give the end-users the CRM functions that they need, on the same environment/desktop. They will not have to login to a different system, switch to another screen, see different colors, follow different user interface rules etc.

Introduce more users into the CRM functions
If you achieve the above, then the usage of the CRM by more users in your organization will come almost naturally. Imagine an Accounting dept. user that sees a problem on an invoice to be able to immediately record the issue on the CRM module of the Accounting system. And immediately a sales support officer to see the problem and take action! Fast, easy, paperless and phone-less! In the same example, if the CRM was not integrated, then the accountant should switch to another screen, search the Persons database to see if this person already exists, create it if it doesn’t and then record the problem.
In other words, traditional non-CRM users will be enabled to new CRM functions. The Management of your Customer Relationships will be enabled for everybody!

Build a customer-centric philosophy of the enterprise
Adding new users on the “CRM vehicle”, will result in turning your enterprise towards a more customer-centric philosophy. This leads, in my opinion, to extroversion, which is definitely a target for modern-day enterprises.

SaaS Pricing Models (part 3)

2010-04-29T16:32:00.000+03:00

In the previous posts we unveiled a number of different pricing models for SaaS applications. In this turn I’d like to explore the reasons why similar products, priced with similar models, can vary so much, in terms of final price.
Let’s just remember that the two basic elements of costing are:
a) Initial Fee (or start-up cost – this can even go down to zero)
b) Periodical costs per “unit” (whatever this is…)

Multitenant vs single tenant
It is obvious that if you board a single-tenant solution, you will be provided with your own server (physical or virtual), your own database instance and your own application instance (executables or whatever this is). All of these require additional effort to support and maintain from the Vendor’s side. And this will obviously reflect on your costs. In addition, initial setup will require additional effort that simple does not exist in case of multi-tenant solutions.

Level of application parameterization
If the application supports extensive parameterization then this will cause additional effort on behalf of the Vendor (even if you won’t be using some of the system features, they are still there and require proper parameterization).
Moreover, extensive parameterization may provide more than one ways to tackle an issue. In that case, consulting services may be called-for.
You can expect higher charges if you are buying a “big” system to cover “small” needs.

Internal effort of uploading (usually perceived as “trivial”) data, such as customer file, warehouse codes etc.
A common problem in these cases is that the Vendor already supports some kind of uploading mechanism, but chances are that the Customer will not provide the exact file format that the Vendor supports and/or there will be data purification issues (not known beforehand) and/or the new SaaS system requires some information (data fields) that you simply didn’t have in your previous system.
This creates a nuisance for the Vendor (not to mention delays in the implementation!). And, as always, “nuisance” means “money”

Number of modules and business functions that are covered
You want to find a piece of software that does what exactly you are asking for. But it is possible that what you like best is larger in scope than your actual needs. This vendor has done a larger investment on that product than the guy next door. And this is going to affect the overall pricing. Of course, it is the vendor’s task to see you actual needs and come up with a “logical” charge. But “logical” is again a number range and not an absolute! It is your task, buyer, to balance what is offered to you versus what is being asked of you.

Security features that are (or could be) installed
This is a big discussion, but I think you get the point, right? The Security issue is (and will become even more) hot. In fact, it is one strong reason why some buyers reject the SaaS idea, to begin with.
Let’s just say that security can be physical (data center, firewalls etc.) and logical (software etc.). All these things cost money that the Vendor must spend in order buy and then maintain the entire infrastructure.

SLA level
This is another significant cost factor. The Buyer should be very careful on the Service Level that they will require. Do you really need 99.9% for, say, a back-office Accounting subsystem?
Now, to distinguish between different Vendors, we must also remember that, depending on a number of factors, same Service Levels may have significant differences in terms for internal cost for the Vendor.

Nationality of the Vendor
The application is on the “cloud” but the programmers of the Vendors are residing somewhere! And they have a level of salaries, expenses etc. Therefore, the physical location of the Vendor can play a significant role in the overall cost of the solution. The phenomenon is more intense when the time comes for Professional Services or Customizations that are asked by the Customer and the Vendor is costing them (usually on a time-and-material basis)

Different “scaling” perception
Scaling usually exists, but volume-based discounts are perceived differently by each vendor. The scale can be 4,6,8% or 4, 10, 18%. Then, although two solutions start from a similar base price, they diverge significantly as volumes increase. This is a significant point of attention for big Customers.

Periodicity of payments
When increasing periods between payments, the cost of money saved by the vendor is different, depending on where the vendor is actually located. Local factors such as bank interest rates for business loans are obviously taken into account by each vendor, internally.
In addition, certain periods may or may not be offered by a Vendor. E.g. a vendor might not want to engage in a monthly payment cycle, even if the customer requests so.

“Customer support” level and functions offered by the supplier
The more “open” a Vendor is to Customers’ requests of any kind, the more “expensive” they tend to be. E.g. if a Vendor is open to “any” customization request, then he must have developed the mechanism to support this: hot-stand-by programmers and testers, very frequent upgrade cycles, complex “release planning” etc.

These are the reasons why prices can be so different between SaaS vendors. And these are key aspects that Buyers should also examine when examining a SaaS offering. The Application itself does not represent 100% percent of the deal!

SaaS Pricing Models (part 2)

2010-04-08T20:45:00.002+03:00

In this post we shall continue with the discussion on several Pricing Methods of SaaS that started in the previous one. Here we go:

Pricing per Transaction: This is an entirely different model. In this model, we are not counting users, time or modules. A business application is offered as a whole (in most cases a core-business-function type of application). The pricing is done on the basis of transactions done by any number of users in any time unit. Of course, then main thing here is to define what a transaction actually is.
For example, in banking applications a “transaction” could be one complete loan application (of course, technically speaking, this is not ONE transaction, but business-wise it is). It could also be a cashier transaction from the bank teller. If this is an outsourced Credit Scoring function, then a transaction would be one score result (regardless of the number of loan co-applicants).
Another example is this of an accounting application: A transaction could be one line on the General Ledger of the company or a complete journal entry.
This model is very attractive for businesses that pull their earnings out of single transactions and therefore it looks logical to them to also link the IT costs to these transactions (this is the example of the bank that generates revenue out of loan interest). In that sense, the previous example of the accounting application, although clean and simple, does not look quite viable: The enterprise does not generate revenue from accounting transactions. Accounting Transactions are the mere result of some other business process.
One more thing: In this model the vendor must be extra-cautious: he has to somehow measure expected volumes of transactions and come up with an offering that is neither too cheap nor too expensive. For example, if a bank gets €200 for loan expenses plus an average of € 100 in interest (on the first installment only) and accepts 500 applications per month, that gives us: (200 + 100) * 500 = € 150,000 per month. If the Vendor asked for € 1 per transaction, then this would be classified as a bad deal for him! A logical number could be, say, 5 € per loan, which is € 2,500 per month. Now, let’s see this example from the side of the customer: This number (2,500) is fair enough for a bank. But if you tried to get this amount of money from a, say, SMB for an ERP application, then you would be out of the door in the first 5 seconds!

The flat-fee method: This is a very simple method that can be used for “limited scope” applications, which in addition, by definition, cannot have a large number of “seats” (=users) in the Enterprise. E.g. a Fixed Assets accounting module, where one data-entry user and one accounting supervisor are just enough. In that case, the vendor could offer a fixed cost per year. In the remote case that the two users become three, the vendor loses money, but the possibilities of that happening are small. And in any case, the vendor has gained a happy client, because he has offered a standard price – clean and simple.

Pay for success: In this method, the vendor becomes part of “the business problem at hand”. He will initially charge an amount of money for his SaaS application (lower than the “industry standard”, whatever this may be!) but he will expect to get more if the Customer’s business grows. Therefore, he wagers, so to speak, that his software will actually help the customer grow his business.
This is not a very frequently met method, but being as aggressive as it is, I would bet that it would attract a lot of customers. Especially those who seek an IT strategy change as part of their overall business transformation.

Apart from the periodical payments, we shouldn’t forget the “one time costs” that most vendors require: Upon activation of the enterprise on the SaaS environment (or the official signature of the Services Contract) the customer is expected to pay a “start-up fee” which covers the costs of the vendor for the time and effort taken to parameterize and activate the customer’s “space” in the Cloud. It may also cover additional services such as initial load of the existing data from the customer’s old system etc.

There is one more thing to comment: Scaling. In most of the above models, the vendor will most often apply a scaling method, too. The more users are added in the system, the lower the “unit cost” will be, etc. This is a clear “discount” logic with which everybody wins:

The vendor uses “economies of scale” to lower his costs and therefore his pricelist.

The customer sees immediate benefit for his “newly boarded” users. Therefore, he receives “incentive” for boarding more and more users and thus automating his business more and more.

And a final word on periodicity of payments: In many cases the “per month” periodicity is converted to larger time periods; say every semester, every six months etc. This is done in order to decrease administration effort for both parties (the supplier and the customer – imagine being obliged to issue an invoice of $50 every month for every customer!). Also, the vendor can be paid in advance for the next period and this can lead to additional discounts for the Buyer. This leads to longer, stronger commitment and relationship between customer and vendor.
You can clearly see that the discount “workarounds” or “opportunities” are large in number. Therefore, we can safely assume that there is a SaaS Pricing Method for everybody. Whether you – customer – want to focus on business results or user volume or stronger commitment and partnership with your vendor, you have a variety of options to get better deals.

One can think and devise other pricing models that borrow elements from the above. E.g. I could also imagine a mixed model, based on “per module and per GB”. There is no end to what the Vendor can think of (and value). Therefore, for all you buyers out there, you can be sure that there actually is a pricing model that best suits your needs.

In the next post we shall take these methods for granted and explore why similar Pricing Models for similar Applications can diverge so much from each other. How can a vendor charge you for X dollars per user and another charge you for 2*X ? Stay tuned…

SaaS Pricing Models (part 1)

2010-03-25T10:38:00.001+02:00

There has been a lot of discussion of how a SaaS offering is priced. Different vendors use different pricing models. To the untrained eye it may seem that they don’t know what they’re doing. But, obviously, this is not the case. Vendors have thought a lot before applying “this” or “that” Pricing Model and you can rest assured that they’ve also done their competition research.

Today, we shall explore the different Pricing Models of SaaS (we shall focus on SaaS; what you are about to read does not necessarily apply to PaaS, IaaS or other forms of “aaS”). We shall also try to approach an answer on why similar pricing models of similar applications can diverge so much from each other.

Pricing per user, per month: This is a very common practice that reflects the fact that the criticality of the application on the Business functions is proportional to the number of users that are using it. It is attractive to the Buyer because it is very clear to him what is going to pay on “day one” and what in the next “days”. Finally, this model is very helpful for seasonal businesses, when they need to periodically increase/decrease their user count. This is very close to Microsoft’s philosophy “pay as you go”.

Pricing per user, per month, per module: This is a model very similar to the previous one with the sole difference that the Vendor requests you to acknowledge that using more features of the application means that the application becomes more business-critical for you and therefore you should pay more. In addition, “more functions” means more data storage, more technical administration tasks for the vendor and increased maintenance requirements to the vendor by you. And this has a direct impact on your costs.
This model is also clear to the buyer but in some cases it may indicate that the supplier is trying to gain more money with each simple “click” that the buyer is doing (“So, now that Mary was also granted access to the CRM module, you have to pay me $5 more, per month”). This could be a possible drawback in Eastern-thinking countries or cultures such as Greece, India etc. Also, if you try to follow the user authorities “to the letter” in order to be 100% accurate, this could lead to an administration nightmare. For this reason, when this model is applied, a clause in the Services Contract could read something like “reevaluation of the user rights will be done every 6 months. If significant changes are found, then the monthly fee will be re-negotiated”.

Pricing per month, per module: This is a simplified model where the vendor assumes that the number of users will not significantly change and is charging for a standard fee per month (and possibly per module). What is implied here is that the application, by definition, cannot be used by a large number of people; perhaps because it is outside the mission-critical definitions of the Enterprise.
A perfect example of this model could be an HR system: It is typically used by a small number of employees (or “given number” if you prefer) and they are doing trivial tasks. It doesn’t matter if the Enterprise has 30 or 150 employees. The system will be used by, say, 3 people (the HR dept.).
But look at this: If the Enterprise suddenly decides to apply “self-services” in the HR sector, then the number of users will suddenly explode from 3 to 150. Then, this pricing model may not be suitable any more…

Pricing per GB: This is a model suitable for cases where the application does not offer “tons” of functionality, but requires lots of disk space. Imagine a Document Management application for higher executives of the company. The number of users is, by definition, small and not likely to increase. But the volume of the data hosted in that application is very large, because it includes multi-page contracts, scanned images etc.

We shall explore more Pricing models in our next episode. Stay tuned!

Is SaaS an enemy of the IT Manager?

2010-03-20T12:36:00.001+02:00

The Internet is full of comments and blog entries that praise the benefits of SaaS, against in-premise. I have also done this (praising)! Of course, most people accept that in-premise has not reached its end (and first of all, Microsoft that preaches “S+S”, Software plus Service); but also most people see the benefits of SaaS…

OK, so why don’t “most people” embrace SaaS in an “absolute” way? By “people” I mean the in-house IT managers of the Enterprise-Buyer and by “absolute” I mean “right here, right now”. We ARE in the middle of a financial crisis and we MUST cut down on internal costs, NOW, right? Today, I shall explore the reasons why the IT Manager is still reluctant to embrace SaaS and also try to answer each one of his/hers concerns. So, what is the average (and forgive me for saying this) and not so SaaS-educated Manager thinking?

I will have no control on the critical business applications, like I do now. Wrong: You will still be the key player on designing user procedures and deciding on Change Requests. You will still be the one who gets input about the user requirements and outputs technical specs to your SaaS vendor. In one word, you will continue to have the same control on the app, as you used to have. The only difference is that you will not have control on the programming itself. Do you really care about that? If yes, then you should also have a look at the PaaS delivery model. But that’s another story…

I will have no control on the security issues. Wrong: Any serious SaaS supplier must be in a position to a) provide you with a solid security plan and b) adapt and adopt any special security guidelines that you might have. You might be charged extra for these services and implementation, but you would spend this extra money anyway, right? Let’s face it: Chances are that your new SaaS system is more secure than everything you’ve built before, in-premise. Everybody knows that in-house development often makes “discounts” on security issues…

My role will be downgraded. Wrong: You role is still important. In fact, you now have the opportunity to move to the next level: You can become a valuable player in the Enterprise business design, instead of holding yourself back with all that trivial technical issues. Because you already know all (or most) business functions of your Enterprise, you could be the all-around player in all management decisions. Everybody will have a better chance on focusing on the business objectives and most of all you.

My staff will be decreased. It is possible that this might happen, but not probable. Some roles might not be required in your Department organization, but chances are that none of your current job positions will be eliminated: You still need the LAN guy, you still need the tech guy to fix the printers, you still need some programmers for custom development, MS Access databases, ad-hoc reporting, to say the least. In case that the headcount actually does decrease, this will work for you and not against you. You will be the one that decreased the IT costs of the Enterprise and for that you are entitled to a big-fat bonus!
Of course, we should never forget the human side: What shall become of the people that the Enterprise has laid-off? No problem, job positions are not lost with SaaS. They are just moved elsewhere: To the growing SaaS-vendor’s headcount, who is in constant need for new recruits, because YOU bought from him and helped him grow. It’s like the 70’s, when Computers first came in the Commercial businesses: Were job positions lost? A few. Were new job positions created? A lot more…

The very essence of SaaS is about letting the Enterprise focus on its core business functions and not deal with trivial IT issues. At least in Greece, in the 80’s, 90’s and 00’s we have seen destructible results from cases where the Enterprise perceived IT as a non-value-adding operation in the Organization and for that reason all IT issues were tackled in the wrong way: fast and cheap. The result was big costs (“cheap” just backfired!), high expectations and bad results. I would bet that this was also the case in other parts of the world…

SaaS is coming to take a large number of problems off your shoulders and convert you from CIO (Chief Information Officer) to… CIO (Chief Innovation Officer)!

Integration vs Best-of-breed

2010-03-13T10:44:00.002+02:00

Today I shall dive into the waters of two different implementation philosophies or “schools” if you prefer: What is the best solution for enterprise-wide Software? One integrated system that “does it all” or a selection of systems/modules, each of which is (or tries to be) the industry leader in its sector?
It is not an easy answer and I’ll give you a hint right from the start: It also depends on local market habits.

First, I’d like to share a couple of experiences that totally changed the way I (as a software supplier) see things:

During my company’s research of the automotive industry in USA and its effort to establish its presence there (in the US), I shockingly found out that there are car dealers out there that use 3 or more systems to do their job: A dedicated system for the car sales, a system for the repair shop, one more for the parts management and nothing regarding Accounting (this is something that their accountant is doing in a “black box”). My first reaction was: “are these people living in the previous century?”, but no. It’s nothing like that. These people have selected the logic of “best-of-breed”. And, rest assured, they have good reason for it…

Now, if we look at the Greek practice (and perhaps the south European, too) we see an entirely different image: If you want to claim that you have a “good” DMS (Dealer Management System) you need at least these modules: Car Sales, Inventory Management (parts and cars), Repair shop, Basics of CRM, Basics of Accounting. More advanced systems would offer advanced CRM, integration with email, SMS, full accounting systems, payment interfaces, financing module, time-keeping module for the repair shop etc. Even small vendors are able to provide out-of-the-box some level of functionality in all these areas!

Why are these two worlds so different? Who is right and who is wrong? Let’s have a look at the reasons that one would decide to go to this or that direction and maybe you’ll be able to decide for yourselves:

Enterprise-wide coverage of business functions:
This is main reason why one should choose a “all-ion-one” system. On the other hand, by definition, a BOB system will not cover all business functions.

Completeness of each module:
An Integrated system requires a lot of effort and investment on behalf of the supplier in order to reach “max” degree of completeness. And this cost will probably be reflected on the product’s price. It is safe to assume that no integrated system will have reached the completeness of a BOB system.

Integration, sharing of data across modules:
It is safe to assume that an Integrated system will follow the logic of “data entry once, share data across”, while in a BOB system data redundancy will exist. The user will need to re-enter data from one system to another. One could go about this problem if one has implemented the appropriate interfaces. But this will also inflict extra costs.

Ease of use, learning curve:
Any user would be happy to learn one system and do it all from it. Also, the look’n’feel would be the same, system-wide. Customer-centric or, in general, entity-centric logic would be expected from such a system.
Different systems will inevitably raise questions like “this one has a worse customer screen than the other. I just can’t get used to it”. Also, you can’t avoid the establishment of different user habits in different systems. Finally, the entire relationship of your enterprise with your customer will be almost impossible to picture. This will cause you a lot of pain in the CRM area.

Extroversion:
If we assume that an Integrated system also includes CRM, then a degree of extroversion should be expected. If this is a web system, then email and possibly SMS functionality may also be expected.
A best-of-breed is more likely to have implemented “interfaces” with other systems that are important for the business function that the BOB system is serving. E.g. a F&I system will most probably have ready-made interfaces with large Finance Institutions.

Ease of Maintenance:
The integrated system has one database and is running on one (?) server. The vendor of this system is just one. On the other hand, of the system fails, then you experience down-time across the enterprise!

Relationship with S/W supplier:
If you have bought an Integrated system, then you are a relatively bigger part of your supplier’s revenue and he is the one to answer all questions and tackle all issues. The relationship becomes stronger and in the future you may be eligible for some kind of discount!
On the other hand, BOB systems are easier and cheaper. Therefore, the supplier seeks to sell more “pieces” than the Integrated System supplier. It is not probable that you will ever reach a relationship as close as the other case.

Security:
In an Integrated system, issues are expected to be somewhat more complicated, although I wouldn’t expect a big hassle.

Expandability:
Functionality extensions would be more difficult to implement in an Integrated system, due to overall system complexity. For example, if you add a new field called “birth date” in the customer screen, who is authorized to see and who’s not? For whom is this field mandatory? You get the idea?
In a BOB system, functionality extensions would be easier to implement, although the degree of innovation should be expected to be lower that the integrated system.

Interfaces:
A BOB system is more likely to have a number of “targeted” interfaces out-of-the-box.

Total Cost of Ownership:
It’s hard to say, but in general when buying an Integrated system you pay a somewhat higher initial cost but you “take it all”. Plus the fact that the annual maintenance fee is very well defined and probably less than the sum of the fees of the other BOB systems.
With the BOB solutions, the TCO is likely to rise also due to the fact that you will need more servers to host these (technically diverse) systems. Plus the system software licenses. What happens if one systems runs on Windows and another in OS/400? One uses Oracle DB and the other IBM DB2?

Consulting needs on behalf of the Buyer:
An integrated system is expected to be more complicated. The need for an external consultant or periodic reviews is higher while in the BOB scheme specialized consultants will offer their services and it is more than likely that, over time, they will have made a lot more research in their field of expertise, thus providing you with more educated answers to your questions. Of course, shiny examples like E-ON INTEGRATION, do exist!

From the above it is clear that the balance is not clearly in favor of the one or the other practice. Look deeper at yourselves and your enterprise and decide…

Customization: an enemy of SaaS? (part 2)

2010-03-05T10:46:00.002+02:00

This is part 2 of the same issue: Is Customization an enemy of SaaS?
In the previous entry, I referred to some examples that will create pressure to the SaaS Vendor because a) these Change Requests are “logical” or “rational” on behalf of the Buyer and b) they are technically complex.

Now let’s see some more aspects of the problem:

Example #3: Look’n’feel
Let’s assume that your SaaS platform has covered some ground in the area of personalization, color schemes, logos etc.
Now, a new customer comes along and requires some extra elements of personalization that your app does not cover. E.g. I recently hit on a case that the customer wanted the color scheme in all web forms to change! Another customer said that “the correct way to place fields in the customer file is last name – first name and not first name – last name”. He actually wanted to swap the positions of these two fields because he felt that his users will have difficulty adopting the “layout of the new system”. Questions:

Do you accept this kind of change?

Do you dare say to the end customer that “small changes like that” will cost him $ XXX ?

Where does this “change-this-change-that” end?
Be careful of what you answer. It’s more than likely that other SaaS vendors will answer… differently!

Example #4: Reporting
Over time, a number of reports has been created and you probably give these reports for free to your new customers. But new reports are requested from time to time and you charge the requestor in order to develop them. This will soon create an enormous number of reports inside the system and you will have to somehow manage this volume and also the different versions of the same report per user (e.g. have you ever seen the “monthly sales report” of two companies being the same?). If the report is pre-fabricated in the system (i.e. there is a specific program that creates a specific report), this can soon end-up in a nightmare. The solution to the problem is to create these reports through some kind of report generator. Does your SaaS app have one? If not, then can the Buyer buy another software and “plug” it to your SaaS database? If yes, then there is a possible security risk that an external system plugs and interrogates a SaaS (multitenant) database! Therefore, you have to think of new ways to raise “Chinese walls” between your tenants. Or maybe, you don’t allow access to your main database; you build a kind-of MIS database “beside” the main database of the system, so that the external interfaces interrogate a “safe” environment (and the cost is obviously all yours). Now, you see how a simple thing like “reporting” can be a real pain!

Example #5: What happens with project-scale changes after “disembarkation”?
In my previous blog post, in example 1, I dealt with the issue of “heavy customization equals project”. And then I talked about the complexity of the version-control. Now, I’d like to highlight another view of the same problem. Suppose that this big request comes during the early stages of your pre-sales function. You try to convince the customer to board your SaaS app and you will form and execute a customized project for his complex request. Now I will play the “devil’s advocate” (i.e. the customer!) and ask you the following:

How much does this project will cost me, since you will develop new functionality that will enhance your position to the market and, giving you more revenue? Shouldn’t I get a share of that revenue?

What happens if I decide to disembark your SaaS app? Is my initial investment on the “project” going to be lost? Or will you reimburse me for that value?

If I am reimbursed, will you add interest for the money I invested on your SaaS app X years ago?

I hope that the above gave you a glimpse of how small problems become nightmares in a SaaS environment. If you are a buyer, then you should consider your specific needs, complexity and business culture and maybe you will find that SaaS is not the right solution for you. Or maybe, SaaS is OK as long as it is not multitenant.

I think that we have been lead to the simple conclusion that “in-premise is not dead yet!”. And this comes from a SaaS enthusiast like myself…

Customization: an enemy of SaaS? (part 1)

2010-02-27T21:20:00.001+02:00

Today I shall examine the issue of Customization on a SaaS (focus on multi-Tenant) environment, where the SaaS application is a business application and not a tool. By the term “customization” I do not mean the Localization (e.g. regional settings per user, area-specific rules such as taxes, VAT etc.); for simplicity reasons, I shall assume that all Localization issues have been resolved and examine only various aspects of Customization.

This post intends to give IT managers and SaaS Buyers in general an idea of the possible challenges there may face when they “board the SaaS vehicle”.

In order to illustrate the issues, I have selected some quite common “Customization Requests” that SaaS Buyers raise (remember that we are talking about a business application):

Example #1: Functionality enhancements – part 1
When we are talking about high-end business applications, such as an accounting system, a sales & invoicing system, a retail banking system etc, we can assume that the Buyer will use this application for its Core Business Functions. Also, supposing that this Buyer is a leader or innovator or otherwise pioneer in his field, we can assume that he may present a series of a Change Requests that will significantly affect the SaaS system (in his effort to maintain the leadership and innovative thinking, in his market).
In this case, heavy customization will be required and this can only be done on a project basis: the software vendor or another consultant must work closely with the Buyer and build up a Project. We know how this is done with on-premise applications. But what about SaaS? After the analysis is complete the software vendor may find that the changes required are huge (this is not the main problem) and that they may conflict with other Tenants’ specifications (this is the problem). Consider the example where a warehouse system has a 3-level structure to define an Item in the Master Catalogue and a new Buyer requires that this is extended to 4 levels. What is the solution? You cannot stick to 3 but if you want to make it 4, then you should consider what will happen with the other Tenants. Will you enforce the new 4-level logic on them? Probably not. You most likely have to devise a way to make this 3/4-level structure, parametrical. So, each Tenant will be able to select whether he wishes his warehouse to work with 3 or 4 levels. This can be done, no doubt. All you need is good programmers and EXTRA MONEY. This is the catch. The Change Request of the new Tenant can be served but the cost is significantly higher than the customization of a presumed in-premise application!

Example #2: Functionality enhancements – part 2
Now, let’s assume that the previous Change Request, although complex and costly, has found its way through the “corridors” of the technical analysis and budget approval. The software vendor is now ready to start working and in a few days/weeks/months the Change will be delivered on the server. Right? Wrong! It is very probable that the vendor has more “heavy” requests like yours, in the pipeline. And it is very probable that he is pushed to deliver in short time by other Tenants, just like you push him! This may result in an endless cycle of Version Design & Control: The vendor will keep trying to fit all these big requests in a time schedule that doesn’t find you (or the other Buyers) in agreement. And so, your Change Request is postponed and pushed to the next release and, and, and…

The above gave you a couple of examples of how complex requests can a) cost more and b) be delivered late, in a SaaS model. Lesson learnt for Buyers: Try to rationalize your volume and complexity of Change Requests. Otherwise, seriously consider the in-premise delivery model.

There are other examples of Change Requests (of bigger or smaller complexity) that we shall tackle in a future post. If, however, you really need these Customizations, then there is another solution… Until then… keep your users on a tight leash (that didn’t sound that bad, did it?)

Business Transactions through Cards and Cheques

2010-02-20T09:45:00.000+02:00

The Greek Ministry of Finance recently announced that, as of 1/1/2011, all “business transactions” above 1,500 € will be done exclusively through credit card or cheques and drafts. Today, we shall examine what this means for the tax-collecting mechanisms, what implications are going to emerge but, most importantly, what it means for software vendors (for whom this column shows particular interest in).

First, let’s define what a “business transaction” is, in this context. There are two kinds:

B2B: One company or enterprise pays another legal entity for its services or products.

B2C: A customer pays the company for its services and products.
In the first case, the drafts and cheques will dominate, while in the second case the credit cards will (there used to be drafts – “grammatia” – in the Greek market but nowadays they are limited). You can also think of variants of the above, but the main idea is the same..

What does this new “method of payment” mean for the tax-collection mechanisms?
I think that this measure is moving to the right direction. If money change hands not as cash but in another form, then, by definition, there is actual proof of the money transaction! Therefore the tax-collector can ask “why this transaction happened? What was sold? Where is the actual invoice?”
Regarding individual transactions, we also see benefits. If the company is obliged to take your money through credit card, it is becoming less and less easy to not issue a sales invoice. If an invoice does not exist, then why did the company take your money in the first place?!

What are the implications involved?

All these transactions will obviously pass through banks (and their computer systems). The banks must be ready for a sudden increase of the data volumes and flexibility in problem solving. We can also assume that the State will require new summary reporting for the volumes that are transacted through cards and cheques.

Now, let’s hope that the banks will not find a way to irrationally increase their “services fee” just for executing a State-regulated task!

A lot of new people – that still resist “plastic money” – will be obliged to issue at least one credit card. This will definitely increase bank revenue but, most importantly, the volume of “private lending” in Greece. A card is basically a loan and, as such, it is very probable that it will create overdue interest!

Elderly people will also be obliged to join this game. So, we can expect “honest mistakes” to rise in number. The banks must establish mechanisms for quickly and securely resolving these issues.

What do all these things mean for the software companies in Greece? Opportunity! Companies will need new software to keep track of these “new kind of transactions”. From personal experience I know that a lot of SME’s keep track of their cheques and drafts “by hand” or in EXCEL. Regarding credit cards, they do have POS’es from one or more banks, but they register these transactions in their computer systems as either cash or with just basic information, entered in some silly “comments” field of their software. The margin of error is very big… I will try to better define “opportunity” in these next lines:

If an enterprise has a lot of credit card transactions, it is logical to request the POS functionality INSIDE the cashier’s software module: The user prepares the invoice, as usual, but when he selects “payment through credit card” a POS simulator pops-up and the transaction is done on the computer instead of the bank’s little machine.

The software must able to print reports of the daily credit card transactions for validation etc. It is probable that these reports will also be requested by the tax collector, too.

It is also probable that monthly or annual relevant reports may be requested by the state (and in electronic format, too).

Regarding drafts and cheques, the increasing volume will drive buyers to purchase new systems (or even modules of their existing systems) for the “drafts management”. I remember, back in the 90’s this was a hot issue, but not any more. Well, I predict that it will once again become hot!

Let’s just hope that this will be a real opportunity for software vendors to create something new and earn some good money in the process. Let’s hope that these systems (that will surely emerge in the market) are not sold for… 100 €, thus killing once again the Greek Software market. We are talking about true value to the end-customer and this has to be paid…

SaaS against in-premise

2010-02-14T10:09:00.003+02:00

The SaaS delivery model is gaining more and more. Especially in hectic times like these, reducing costs more important than ever before. This post will attempt to give an idea of how SaaS can bring benefits to your organization, but also how new considerations emerge to the mind of the CIO and the CEO.

First of all let’s define the SaaS delivery model. You may find a lot of definitions about that on the Net, but for this discussion let’s keep it simple: SaaS is the delivery model, where the enterprise does not “buy” the software and does not “install” it on its servers. On the contrary, the application resides on some remote host and the enterprise pays per usage of the software (obviously, over internet). Therefore the software is “rented” instead of “being bought”.

What are the main advantages of the SaaS model?

Zero cost of initial investment of the application software

Zero cost of initial investment of the system software (operating system etc.)

Zero cost for the building of the infrastructure (servers etc.)

Zero cost for the maintenance of the infrastructure? This is one very important factor and people sometimes tend to forget about it. Maintenance includes salaries for dedicated or semi-dedicated personnel to keep the service running, “side-hardware” costs (such as backup devices) time consumed on trivial tasks (such as antivirus protection, hardware failures, the respective maintenance contracts etc). Let alone the fact that probably the IT dept. has to build some skills that it didn’t have so far.

The above is a collection of “financial” advantages of SaaS. On that you should add the cost of money that will not be paid upfront!

Now, let’s have a look on the technical aspect, too:

SaaS vendors tend to provide upgrades of the application software very often (much more often than the traditional delivery model). Therefore, you may assume that new functionality and bug fixes are received very quickly

Buying SaaS, you become a member of a larger community of users. Remarks and change requests coming from this community will result in more frequent functionality upgrades. The cost of it will either be borne by the Provider itself, or split between all customers (in the long run), which will have almost zero effect on your bill!

If you don’t like it, you may stop it at any time. In that case, you need to be aware – beforehand – of what happens with your existing data. All providers will give you a solution or two. It’s up to the CIO to decide if these solutions are adequate and acceptable by the enterprise.

Guaranteed up-time. Close to 99%, in some cases. This is better than an internal IT dept. can provide (and guarantee!)

OK, so if SaaS has all these advantages, why isn’t everybody following this path? Let’s have a look on the other side of the coin:

The SaaS delivery model is not suitable if you require heavy customization on a – otherwise well-defined – process. If you wish to have the debits on the right and the credits on the left (!), then probably your SaaS application cannot do it!

There are security considerations, for an application that runs on a remote server (outside your premises). In some cases there are regulatory constraints. E.g. what does it mean for a bank to host its customer database and customer analytics, off-premise? What happens if this database is compromised?

Before you buy, you must measure when the SaaS bill will exceed the in-premise investment. Perhaps, this will never happen, but there are case where the service is expensive and you reach that “turning point” very fast (e.g. in a couple of years)

There is no doubt that SaaS offers significant advantages on the enterprise. First but not last the reducing of TCO (Total Cost of Ownership). There is also no doubt (?) that SaaS will dominate. If you are interested in learning more about how we have done it, contact me directly!

Front-end Retail Banking Applications (and more)

2010-02-10T20:53:00.006+02:00

In this day of financial crisis and extreme competition between banks in the Retail sector, a financial institution needs to have the ability to serve its customers at a new level.

When the customer goes into the Branch, he needs to feel important. He needs to sit down in a nice office and a bank officer to come, sit with him, discuss anything that the customer is thinking about, give him advice and immediately issue offers for various banking products. “What? You don’t have a savings account with us! Let me just apply for one and then we continue our discussion”. This is how it should be. Forget about lines of people standing and waiting for their turn.

This is pretty important but… is that all? No, the bank must look farther: customers that “voluntarily” go inside the Branch are OK but what if the bank were able to go to the customer, itself? Consider the following examples:

How would you like to go and buy a new car from your local car dealer and get instant credit?

What about the new big screen TV that you were thinking about? If you don’t have the money, don’t worry; you can get credit if you just ask the floor manager. He will take you to a nice office and you will have a chat…

And while you are at the super market, doing the week’s shopping, why don’t you get the new branded Credit Card of the store? It will give you significant discounts.

You see where this is going? No? I’ll tell you: All these retail POS’es need to have the bank’s front-end system, to immediately post a loan or credit card application and get a response in a matter of minutes (or seconds). And if things are positive, the POS will actually print the loan contract and you will sign it.

Some of you may have already seen it, but not all of you. I happen to know banks that either do not have this kind of capability or they have it through a mediator, who receives Applications and then forwards them to the bank. Therefore, it is the mediator who has the reach-to-the-POS capability and not the bank!

Remedy? Yes: the banks need to deploy front-end systems in order to reach out to the POS. In addition, the bank Branches must be converted to POS’es of the new era. Here are the basic characteristics of such a system:

1) Web enabled. And I will not take “no” for an answer on that one!

2) Unified customer database. Everybody in the network should be able to see the customer’s history.

3) The entire arsenal of products in the hands of the salesperson. See customer analytics and cross-sell.

4) Customer behavior data and black lists. You need to identify “faulty” cases immediately.

5) On-line connection with the back-office system. Loan disbursement must be feasible in real-time.

6) CRM capabilities must be included.

One more thing: It is my strong belief that in an ideal world, all these front-end tools should be integrated with the rest of the system. In fact, I believe that the bank should only have ONE system. Front and Back, it doesn’t matter. Everything is part of the bigger picture. Maybe, this is very difficult for big Institutions where the complexity of the business if high. But when we are talking about small or medium banks (Car manufacturer captive banks, partnership banks with local-only presence etc.), then it’s much easier. If you want to know how this is possible, contact me!

The Basics of Software Production

2010-02-07T09:11:00.005+02:00

From my experience as Software Production Manager, I have created a list of things that a S/W Manager should have in mind. In this post I’d like to share them and maybe get some feedback from you. Please note that this is not a technical article. It is mostly about human interaction and team building. Here goes:
1) Establish team spirit: You are the leader of this whole thing. No doubt about that. But what happens below your level. Are team member competing with each other? Are their roles clear to them? Are there conflicts? Sort it out, the soonest!
2) Assign specific roles: Don’t think that everybody can do anything. OK, this is a hard one when the project is small and has limited resources, but still… you have to try. Let alone the fact that if members feel that you are using everybody for everything, they will quickly come to the conclusion that you don’t know what you’re doing.
3) Give members the “big picture”: You would normally expect that a programmer can operate on “need to know” basis. This is more or less correct; or is it? No, you should try and give them the “whole picture”: What is this project about? Who the new software will help? By what means and processes? What benefits will it bring to the end-user and his Management? You may argue: “Why is a programmer interested in that?” I will answer that the programmer, having the entire picture in his head, can design his code in a more “open-minded” manner. He will know that the “transaction” that he is designing will be used by the module that his colleague is developing right know. He will know that this transaction is time-sensitive and so its user interface should be clean and simple. He will know why “that report” is very important to the Management and so it needs more filtering criteria and ability to sort by column. These are pieces of information that you simply just can’t give them through the Project’s Technical Documentation! Extra bonus: You are giving your programmers some kind of “business training”.
4) Give members “room to breathe”: I know that you are a better programmer than they are (that’s why you have been promoted, anyway!) But they are also IT professionals and they are trying to evolve. Give them room to develop, decisions to make. Yes, they will most certainly make mistakes. That’s why you are there: check, test and correct mistakes. But you must see this as an opportunity to help members grow and – rest assured – in the next projects things are going to be easier. Oh, I should not forget this: This process will somewhat increase the total time needed for the implementation of the project; you might want to include that in your project planning and assumptions.
5) Members are also humans: Don’t push them too hard. Don’t push them more than you need to get the job done. Difficult days will actually come – that’s almost certain. You need them to be in “tip-top” shape when that time comes. You need them to understand that “now, we have a few days of pushing hard”. They will understand. But they won’t, if you are pressuring them all the time! Would you, if you were on their shoes?
6) Be a leader, not a boss: Be ready to execute yourself whatever instructions or commands you are issuing. Don’t ask them to “jump off a plane” if you are not willing to do so! You are there to set an example and not smoke you cigar in you big-time corner office. They are watching you, just like you are watching them. Oh, and something else: You may have your own office, but they don’t; they are working together in shared space. Therefore, you can expect comments flying around like kites! Don’t give them ground to do that. Inspire respect to your personality.
7) Be a friend not a “buddy”: You must have good human relationships with your team. They must not fear you. They must not feel threatened by you. Be a friend to them. Talk to them. Listen to their problems. But don’t be a “buddy”: Don’t go with them for beers every afternoon, on happy hour. Don’t tell them jokes all the time. Don’t disclose personal details of your life, like “I had a big fight yesterday with my wife”.
8) Reward them: I don’t have much to say on this. It’s obvious! But just one tip: First talk to your boss (if you have to) and get his/her OK for some kind of reward. After that, go ahead and make some promises (only the ones that you can keep!). Reward after the job has been done is nice but it’s even nicer for members to have something to wait during all that time of coding, coding, coding!

Welcome

2010-02-06T09:23:00.002+02:00

Welcome to my blog.

It was created with the purpose of providing me (and you!) a means of communicating with each other.

I shall post information and articles from the world of Information Technology (IT), of which I am a member. I have spent all of my professional life in that arena and I have a lot in my mind that I’d like to pass on.

There will be other subjects too, like everyday issues that concern us as citizens of Greece but also members of the global community.

I want to share my thoughts and experiences with you and, at the same time, gain from your wisdom. If you think that there is something interesting for you in here, then… “stay tuned”!

Oh, one clarification: I selected English as the writing language, since the biggest part of the posts will be of global (I hope!) concern and not just local.

Thank you in advance and I hope that we will spend quite a long time together!