Wednesday, May 14, 2014

IT chargeback/showback and SaaS

In this post I’d like to approach the issue of whether and how Software as a Service (delivered of course through cloud technology – don’t let them tell you otherwise!) can assist an organization implement an IT chargeback / showback strategy. For those that haven’t heard the terms before, IT chargeback is the methodology or strategy that applies/allocates Information Technology costs on the business unit that is actually using an I.T. resource (be it software, hardware, professional IT services etc.) Chargeback can go as far as internal expense management where the business unit actually experiences cash outflow (or budget consumption) in order to implement an IT function. In other cases, there is no actual cash movement; all calculations are done on reporting level only in order to have a clear image of the costs incurred by each business unit to the organization, for planning and budgeting purposes. This is called “IT showback” where numbers are “shown” but are not actually “charged”.
But how can Software as a Service assist the organization implement IT chargeback/showback strategies? The answer is “in a number of ways”.
First of all, the very nature of SaaS is “pay as you go”, which means that SaaS costs increase as long as your needs grow. The “growing of needs” can be measured in many ways, depending on largely on the nature of the SaaS product under question and can be tracked down to who has that new requirement. A few examples are the following:
  • Sales department is on-boarding new salespersons so it needs new seats for the CRM SaaS application that is using. Seats are the usual metric for business applications.
  • Marketing department needs additional disk space for new digital material is has generated. Storage figures are the usual metric for large objects storage.
  • Management needs new reports and dashboards to track the monthly business. Such needs are measured in hours devoted to Customer Support Requests by the vendor.
All of the above usually originate from a specific source (business unit) to cover the new needs of that unit. Therefore, the relevant cost can be easily attributed to the specific business unit (or “cost center”, to borrow the accounting term). Now, because the costs are clearly defined in any SaaS deal, we come to the conclusion that cost center accounting of this nature is facilitated by the “as-a-Service” costing model.
Another aspect that we need to factor in is the recurring costs that XaaS does not have. I’m referring to the yearly maintenance cost of a perpetual in-premise license. After initial installation, the customer is requested to pay a standard yearly fee for the maintenance and upgrade tasks of the software installed. This is usually a fixed number and does not follow the growth or shrinking of each business unit that uses the software. For example, if new users are hired in Sales Dept. then the yearly maintenance fee is not increased, if the license scheme initially offered is a “perpetual license” one (which is usually the case). So, even if there is an initial breakdown of such costs, done based on some metric (e.g. number of users per department) this breakdown may soon become obsolete.
One more point to make is that of additional works after the initiation of the XaaS project. The XaaS monthly fee does not include any additional works that the customer may ask. Therefore, whenever a business unit is asking for something new or additional (new functionality, additional disk space etc.) the new cost can be easily attributed to that specific cost center, since SaaS is not an “all-inclusive” deal. On the flipside, a yearly maintenance fee of an in-premise model may include some portion of such additional works. The vendor may for example offer a number of free working hours to resolve issues or implement additional requirements, per year. In these cases, the cost has already been prepaid and it is not easy to attribute this or that work to the corresponding business unit (since there is no actual invoice to forward).
The above show that the “as-a-Service” costing model (and the technology that comes with it – in my personal opinion a XaaS deal cannot work efficiently with in-premise software and hardware, although we have seen such deals) facilitate the IT chargeback/showback strategy of the organization. Of course, that is not to say that this fact should be a decisive factor when the “cloud vs in premise” question pops up; nor that IT chargeback cannot be implemented with traditional costing models. The point is that in this area, too, “cloud makes it easier”.

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.