Sunday, January 25, 2015

How can cloud and SaaS assist ITSM implementation (part 1)



ITSM (“Information Technology Service Management”) is generally defined as the shift from managing the technology stack inside an I.T. Department (or in the enterprise, in general) to addressing real-life business issues that generally come down to Customer Service. In other words, according to ITSM methodologies, I.T. must no longer focus on managing the technology; instead it must set its goals towards aligning with the rest of the business and be an equal player in the effort (design, contribute) towards generating value-added services both for the business users and directly for the customers.
In this post we discuss how “Software as a Service” can assist in setting and implementing such goals. To do this we shall enumerate some “attributes” or “dimensions” that a typical I.T. organization has to address and manage; show how these are transformed from a typical I.T. function to an ITSM delivery model and finally comment on each of them and explore how SaaS can “back them up”.

  • Technology focus vs Process focus: Traditional I.T. functions focus on managing the technology they use or deploy to the organization. A shift to ITSM dictates that the focus should shift to Process. SaaS can assist in this area in many ways: Firstly because SaaS is primarily a web-based piece of software which is accessible 24/7 inside and outside the premises. Therefore, by definition, it relaxes time and geographical constraints, which in turn result to more “liberal” and user/customer-centric processes. In addition, with SaaS modern technology infrastructure, we can assume that the software delivers openness (SOA, web services, connectivity – call it what you like) and integration that surely assists Process Design by the business; remember that Process may entail some interfacing with external organizations in which case modern SaaS apps may have something more to contribute).
  • Users become Customers: In an ITSM delivery model, I.T. does not see people as Users that simply need rights administration, technology support and training but rather as Customers that require a certain level of service. In addition, the word “customer” now also means the actual, end-customer of the organization. I.T. is asked to provide services to them too instead of staying “behind the scenes” and provide the ability just for “technology consumption”. In this context, SaaS has its “measurable nature” to contribute. By measuring usage, each user becomes a customer, probably an “I.T. cost center” which can be accounted for and charged for usage, at the end of the day. That way, I.T. can budget and track expenditure in a quite detailed level. This was also true in the first days of computing where mainframes where used as “time share computing engines” but back then measurements where only high-level: company A used machine X for 3 days and company B used machine Y for 6 days. And that was it. Now, SaaS (with the technological assistance of cloud services) can measure each user and each process separately; also measure variances in the “computing consumption” e.g. when more processors or disk space are allocated to a Process etc.
  • Centralized vs distributed: Traditional I.T. would typically install software on central servers and provide access to local or remote users. Usage could not be measured (other than network traffic per point/hub). SaaS can now be used for detailed measurements. Additionally and more importantly, SaaS is THE best way to achieve distributed computing, geographically dispersed and irrelevant of time-of-day and time-zone. When software is required where the customer is (on the road, on the customer premises, mobile etc.) SaaS can provide what traditional or mainframe computing could not.
  • Isolation or siloed computing vs integrated and mobile: In any SaaS implementation we can easily assume that the Business Application runs on one single instance and data are shared between users, departments and processes; no double data entry and no duplication of records. In traditional I.T. implementations where technology is the focus, there are dispersed servers and databases. Each user is using the server he/she is allowed to and data have to be transferred from one point to another and finally consolidated in a central database for M.I.S. and general reporting. Apart from the technology hassle that SaaS saves in this case, we should also consider how Integrated Customer Service is achieved with SaaS: Whenever a specific customer is present in the “corporate grid”, its data (financial, CRM, historical) are “there”, on-line for everybody to see and process. This has an undoubted advantage for any customer-facing Business Process the organization designs. Take the simple example of retail car customers: For them, it is only natural that when visiting any service shop in the manufacturer’s network, their personal history and that of their car is transparent to all members of the network: instead of the service manager asking “what did you do on your last service?” (a question that most customers would be unable to answer), it would be better to have them say “I see that the time has come for a new oil change, since on your last visit you…”. Now, try implementing that with siloed computing architecture!

In the next post, we shall discus more areas of ITSM that can be better served by a SaaS implementation rather than a “centralized computing” one or even a “distributed computing” of the pre-cloud era. Stay tuned…

Monday, November 10, 2014

How cloud and SaaS can enhance I.T. agility



The advantages of the cloud and specifically Software as a Service (SaaS) are very well known. Everybody’s talking about them all over the net, at forums and in the pre-sales calls of the cloud companies. People are talking about financial benefits that SaaS brings in their P&L, several cost saving factors, security, portability and access etc. One more advantage that is less frequently discussed is this of the agility that SaaS brings in the entire I.T. function, structure and governance. In this post I’d like to focus on this exact point, thinking that maybe it is usually understated.
We must admit right from the start that agility is not a critical issue for some buyers, mainly the smaller businesses that adopt SaaS; for them portability, web access, cost savings may be more important; but what about the bigger fish in the tank? SaaS enthusiasts claim that the cloud is suitable for bigger installations, too. For these installations, qualities like agility, the ability to quickly adapt to new business requests, the ability to adopt new software solutions fast etc. can be very important. So, how is SaaS helping them achieve new, higher levels of performance when it comes down to these metrics?
I will not enumerate the metrics one by one, here. There is a large number of those, after all, and the reader could easily argue that this or that is of low importance and therefore not worth the conversation. Instead, I select to present some qualities of SaaS that make I.T.  more agile and adaptable. Let’s have a look:
  • The easiness of on-boarding a web-based SaaS service makes it even more attractive than the pure functionality the service offers, in the sense that when there’s a pressing issue to be resolved, it’s quite easy to register and start working in a matter of minutes or hours (at this point, the discussion opens for the Rogue I.T.). Of course, that is not to say that I.T. issues must be dealt with in such hasty manner. Due diligence must be executed, software selection process is always there etc. But there can be strategies that enforce a quick solution “right then and there”, while the final solution to the problem is still being investigated or planned. Such quick solutions were not possible in the “old days” when even the smaller piece of software had to be purchased, installed, probably customized and – at the end of the day – maintained as a piece of significant investment, that it was. Hence, the agility; the possibility of quickly solving a problem with a hand pistol while looking into the market for a larger “gun”.
  • In the same spirit as above, we can’t help commenting on the migration process. Migrating your old data to the new web-based service is usually a painless (or less painful, if you prefer!) process than it used to be. It is now clear to the SaaS software vendors that good functionality is not the only quality required to keep ahead of the competition. Fast and painless on-boarding is also a requirement and around this requirement, data migration is a central issue to look at. That’s why some services offer “plug and play, do-it-yourself” data upload mechanisms. And that’s also why the data migration issue is being observed even more closely by some specialized companies in the field.
  • When the time comes to abandon the SaaS service, it is usually equally easy to download whatever data you have inputted or calculated in that service. The form of the downloaded data is not in some proprietary format that I.T. Dept. or the next vendor can’t process. Usually, XML, txt or EXCEL file formats are what is being used. How does this enhance agility? Because migrating onto the new software is no longer a long and painful process nor does it require manual file processing, cleansing or conversion to another readable format. Therefore I.T. managers need to budget less for extra time and resources when they’re asked to estimate the effort of transition.
  • The easiness of adopting a new SaaS service is in direct proportion to the costs involved. We have heard time and time again that SaaS pricing models and Total Cost of Ownership (TCO) makes it easy to adopt. That is true when a new installation is designed. But it is also true when an existing infrastructure needs to be refreshed or updated or enhanced. The total lifecycle of a piece of software can be significantly smaller with SaaS, instead of waiting years to depreciate the investment that the company has made when it purchased a on-premise piece of software. Software is no longer an investment, rather it is a monthly expense and as such the commitment that the organization makes to it is much smaller.
We’ve been talking about “degrees of freedom” (a.k.a. agility) that SaaS brings into the organization, when it comes to internal scheduling, budgeting and costing. But there are also external factors that assist the continuous effort of the organization for I.T. flexibility and fast response:
  • Exactly because software vendors know that customer retention is a much bigger issue than it was for the on-premise software market, they are pushed to respond and act better and resolve issues and bugs faster than before. Churn rates are significantly higher to the Service business than in the License business. Vendors know that customers can move more freely in the SaaS market and thus they (the vendors) need to increase the level of service they provide.
  • Software updates are released must faster and they bring faster resolution of bugs but also significant new functionality, each month or trimester. The old days when, for example, a banking application had a new release every eighteen months are (almost!) over. Regardless of whether a new component was requested by the community or paid for in a Customer Support ticket as a custom enhancement, users see their issues resolved faster and better than before.
  • Role-based authorizations are surely expected in a SaaS application, while in traditional software this may not be the case. Features like that enhance agility for the daily business as system administrators can now configure larger parts of the data entered and the user interface than before. A typical example is that of a central Customer Database where the Accounts Receivable officer should be able to see and change different information than the CRM user. For traditional on-premise software such functionality may not be a standard feature and when it comes down to role-based distinctions perhaps programmer-driven customization is required, which means program changes, release planning, testing etc.

Software as a Service turns software into a commodity rather than a product and as such it is more easily consumed (but also “recycled”!) when it’s no longer needed. In a fast changing world, I.T. is there to assist those agile business processes and models. Therefore, I.T. should be agile, too, in itself. Software – which is only a part of I.T. – must follow this general rule and SaaS makes it more possible than ever before.

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”.