Friday, April 18, 2014

Comparison of Private and Public clouds

So, you’ve decided to move some of your apps to the cloud. The next question that you need to answer is “public or private?”. Each direction has its pros and cons and you’d better look at all possible Performance Indicators before you decide where to lean. Every problem has its solution and every solution has its cost. The term “cost” is usually translated in monetary terms but this is not the whole truth. The “cost” can be compromises that you are willing (or not) to make in terms of security, availability, scalability etc. The “cost” can also be the downside of what today seems inexpensive (for example, the cost of a SaaS application that is quite low to begin with, but requires extensive customization on your existing software to integrate).

In the following table, I have compiled a list of issues that one should consider or address when having reached the crossroads “public vs private”. You see, the cloud has reshaped Information Technology but the very basics of the I.T. realm have not lost their significance: deployment, cost of ownership, knowledge capital costs etc. are some of the issues that have been troubling CIOs across the globe and will surely continue to do so for the foreseeable future. Let’s have a look at them:

Private Cloud
Public Cloud
Security can be designed and implemented according to your needs and corporate policy. Also, it can be revisited, anytime the business requirements change. Obviously, you are free to select the level of security and find the balance between that level and the cost of implementation and maintenance.
You have to follow the provider’s security guidelines. Customization in that area is not very probable or – if it is – it will come for a high price.
Sure, security is an issue that you will examine before you make your vendor selection; but things can get tricky when you find the SaaS application that best suit your needs, but the security level does not live up to your expectations.
Availability is entirely up to you. You can set very high standards but you are the only one who can make sure that these specifications are met. You have to deploy your own resources and controlling mechanisms and you have to periodically revisit the issue and probably budget for new costs.
The positive side is that you don’t have to rely on the “open internet” connection speeds. If you choose to build your private cloud on the backbone of a guaranteed internet service (such as VPN) you can stay relaxed about the throughput of your connected points.
It is not you that is troubled with that headache. As long as you have set your standards beforehand and your vendor can live up to these expectations (through a signed SLA, of course), you can rest assured that the availability will be what you expect.
Of course, high availability comes for a price and you should definitely set the roof to your expectations. The fact that the headache is not yours to handle does not mean that you should go ahead and ask more than you actually need.
You have better visibility over the various cloud components, such as computation resources, storage, network devices and the corresponding bottlenecks.
Your vendor is the one that handles and nurtures, so to speak, the entire infrastructure. They may be extra careful and professional in what they do but they can’t be as time-sensitive as you, running your own business. If, for example, you know that you have increased computation requirements from 19:00 to 23:00, you can plan for it better and more accurately, if you run your private cloud. And if worse comes to worse you are free to select services that will be downgraded in favor of the more important ones.
Because you provide service to only one set of users, the actions for orchestration and planning of the resources can be faster since complexity is lower and bottlenecks are more predictable.
A good cloud provider can perform just as well. They may also have deployed automated load balancing and other resource-planning systems. But it is a question of how fast can they respond and how accurate the can be in their “fine tunings”
Update process
The update process, pushing new releases or bug fixes to your users is entirely in your hands to plan.
Testing of new releases can be planned and executed according to your standards and take as much time as you need to ensure good results.
Also, the implementation of a separate test environment is probably a very easy thing to do and maintain.
In many cases, upgrades are pushed from the vendor with just a small notice (if any).
Also, test environments are not available or, if they are, the test planning cannot fit to your exact schedule. If every customer of that public cloud service was asked when it would be the best time for the test to start and end, it would most probably never be executed.
Finally, it is possible that separate test environments are available by the vendor, for an additional fee.
As in the update and testing process, customization is yours to decide, plan and execute.
In fact, if your governance includes a great deal of “customization” (instead of deploying “best of breed” or “off-the-shelf” products), a private cloud may be your only option.
Customization may be impossible, that’s the worst case scenario.
Customization may be possible but it will surely be implemented by vendor staff, which automatically sets the issue of “additional fees” on the table. Even if your I.T. staff was as capable as the vendor’s, the cost of customization in a public service would be so much more expensive as to cover the vendor’s profit margin, per work hour.
If your enterprise operates under a strict legal framework, then implications in terms of security, availability or other issues may be such that cannot be easily met by the average public provider. Then, the implementation of a private cloud may be the only way forward.
Assuming that your operation framework entails several strict guidelines, you may have a hard time finding a public provider that abides by these guidelines. If you find them, the additional “level of service” (which is translated into additional technical clauses in your SLA) may significantly increase start-up and/or recurring costs.
Take banks for example: how many of them operate in a public cloud?
On the other hand, for SMEs of typical nature (such as service providers, stock movers, retailers etc.) there is no question of “governance”. I.T. function may be totally absent in such small businesses and therefore the Public Cloud may be their best option for deploying almost-zero-headache top-of-the-line applications.


You may get the feeling that Private Cloud wins over Public in all of the above performance indicators. This is a generalization that is not at all true. As always, you have to carefully put down your requirements (both business and technical ones) and see how far you need to go. Then put these requirements on the balance with the budgeted costs. Finally, make your market research and find out if there are public services able to meet your standards and a cost that you can take today (and also with some buffer for the near future). Then, the answer to the “private or public” dilemma will start to be made clear…

Sunday, February 16, 2014

How cloud ERP can help you in ways that traditional products can’t

Through this channel I have been talking about the advantages of cloud and SaaS products for a long time. In this post I’d like to focus on a more specific area. An area that contains a large pool of potential customers, who at the same time are still facing basic problems in their journey towards a “computerized enterprise”. That of small business ERP and especially the Financial ERP.
By the term “Financial ERP” we define the software that performs the basic functions of book-keeping, sales and purchases, stock keeping customer/vendor order management and perhaps some more like basic workflows and some kind of business intelligence. These are requirements that small and medium-sized businesses are seeking to approach first, or they have already done so with not much success. Also, they are the kind of requirement that start-ups are trying to cover, since they touch the back-bone of the business function.
In this discussion, I choose to omit other, more specific ERP functions such as Production Planning, Capacity Planning, Warehouse Management etc., because if we are talking about a large enterprise that actually needs such advanced software modules, then they are probably large and complex enough to choose an in-premise product and customize it according to their needs. So, for them, a low-end small business ERP is probably not the right choice.
But let’s try to answer a very “hot” question for these small and mid-sized companies: What has a cloud ERP product more to offer than the existing in-premise products? To answer this question, I will not focus on the usual cost benefits of cloud and SaaS nor will I talk about the internal resources issues that an in-premise product will raise for the company. Instead, I think that there is a number of valuable, I believe, possibilities and functionality that cloud ERP can offer which traditional products can’t. The general idea is that a cloud ERP product can bring the necessary extroversion in the company culture. Having a working accounting or Accounts Receivable software is one thing; it allows you to keep correct customer records, track balances and do your book-keeping. And all that is just for your eyes to see! But what if you wanted to invite co-operators to join in and share knowledge, exchange data and participate in common workflows? One way to do it is by building a kind of corporate portal and implement such functions on that portal. But what if your core business software had already such capabilities? It would be easier, faster time-to-market less painful in terms of interfacing, data exchange and internal controlling & reconciliation. And obviously cheaper! Let’s have a look at some of them:

  • You could have regular vendors exchanging data and performing automated account reconciliation with your own Accounts Payable records. To go one step further, you could have vendors logging in your system and actually browse through the A/P records that you keep, so that they can acknowledge their correctness. Furthermore, if problems exist they (or you) could initiate a “disputable items” workflow to resolve the difference.
  • In case of contract-based billing, you could first seek your customer’s approval on an Accounts Receivable invoice before you proceed to the actual invoicing. That way, you would save time from erroneous invoices and the necessary corrections through credit notes etc. The time from invoicing to invoice payment could be decreased drastically.
  • In the above example, additional tools could accelerate response times even more. Email notifications for each invoice issued or for each approval required could be sent to the interested parties, to make sure that anyone who should take some action is immediately “tagged” in their mailbox. That very mailbox would even become their daily “to-do list” as far as your cloud ERP is concerned!
  • Customers could tap in your cloud ERP, browse inventories and make on-line orders. Of course, this idea is not applicable to B2C sales (you have your on-line e-shop for this purpose). But if you sell to wholesalers who need on-line information, don’t care about the e-shop bells’n’wistles and are particularly interested about the whole chain of the customer order fulfillment (not just the ordering part), then having them inside your ERP as business users could have some very significant benefits for the sales process as a whole.
  • A service provider may want to implement a “customer support” web system to accept requests from customers, classify them as tickets and process them accordingly. In these cases there may be a significant number of monthly invoices to attach behind each chargeable ticket. And this could be a manager’s and the accountant’s headache to process and invoice, every month. So a “ticketing” function inside your cloud ERP software (where your customers are also welcome to participate in the workflow) could be a serious issue to consider. There is no doubt that you could implement other kinds of ticketing systems; but an integrated one with your back-office invoicing?...

Once you decide to open your ERP and data to the outside world, the sky is the limit. There is a large number of possibilities and functions that you could design, to best fit your organization, business process and – at the bottom line – your reason for existence in the business landscape. The above are but a few examples that I regularly discuss with business owners (but also drive me to design new products and services).
I don’t claim that a cloud ERP software has the broadest span of functions and the best quality at the same time. But, in an effort to keep things simple for the small and mi-sized business, I would urge anybody to take a look at cloud ERP that meets all the usual requirements PLUS the functions required for the extroversion of the enterprise, before deciding to embark to a long and painful journey of purchasing and integrating the “best of breed” for each function that they wish to implement.

Sunday, January 5, 2014

SaaS: An opportunity for closer cooperation

There are many advantages in the adoption of a SaaS application for the enterprise. A lot of people have talked about cost benefits, ease of deployment and maintenance, out-of-the-box remote access, mobility etc. In this post I will focus on a new opportunity that SaaS is presenting to its customers. This is the potential ability to invite their cooperators (customers, vendors, business partners etc.) to join a common workspace and complete business transactions or share information and knowledge.
For the purposes of this discussion, we shall assume that the SaaS product under question is a web- and role-based application that can support several business transactions and also reporting or BI capabilities.
Now, in the real world each business transaction has to be completed in at least two different systems (one of the vendor and one of the customer). Obviously, there is a large amount of information that is duplicated between these two systems. And this duplication has always the risk of human error, resulting in the two “instances” of the same transaction not coinciding. This creates the need for double checking, communication between the peers after the normal completion of the transaction, emails, time lost and manual corrections in case of actual error.
Also, leaving aside the problem of checking and reconciliation, there is an amount of duplicate work that is done by the peers, anyway. For example, a sales invoice that is issued by the seller is also manually entered in the Accounts Payable of the buyer. Issues like this were tackled in the past by “traditional” technology enablers such as EDI; with not much success I might add. For example, EDI was a great idea but didn’t work out very well since a global standard failed to be devised and followed in a large scale by software vendors.
SaaS brings a new answer to all these questions. Having the ability for role-based access in one single system, one can “invite” external users to enter this space and send or receive information, produce reports and benefit from Business Intelligence features of the application. They could also go as deep as one specific business transaction (an invoice, an order etc.) and act upon it. Here are a few examples:

  • On-line checking of order status (much like any modern e-shop. But what if the seller doesn’t have or doesn’t need an e-shop?).
  • Receipt of e-invoices. The recipients can print them or they can download them in a computer-readable format, to automate their Accounts Payable feeding.
  • Overall accounting statement of the invitee. Frequently needed in some cases to reconcile customer/vendor statements (typically, this is done through emails or phone calls).
  • Invitee to provide their acknowledgment that the business transaction is ready to be completed and amounts and quantities are OK. This would save time for both parties from manual corrections of errors or disputable items.
  • Receive downloadable material that the customer needs, for example service manuals, marketing material etc. The vendor no longer needs to send them through email, keep “sent/not-sent” lists and in general engage its own staff.
  • Automated email notifications to the customer when Accounts Receivable of the vendor mature.

The above examples show that while peers save time from several activities, the invitees receive a better (and automated) customer service which increases satisfaction and potentially loyalty levels. Also, inviters will get feedback on new services requested by their customers and probably, given time, grow their range of “self-service” functions; and all of that because they decided to choose a SaaS product to build their business platform!