Tasos Christidis

Cloud providers cross-selling Services

2019-03-17T12:31:00.002+02:00

In an older post (http://tchristidis.blogspot.com/2010/10/saas-and-outsourcing-function.html ) I discussed how Outsourcers could join forces with Cloud Providers to offer better services to their customers and increase response to additional requirements. In that post, I was building a line of thought based on the premise that a) the Cloud provider (SaaS in my example) did not have enough expertise to pursuit the sales of additional services to a niche or vertical market and b) that the Outsourcer *should* be the one to lead the joint effort. That idea is still valid and we have seen some outsourcers do just that: Sell their services, accompanied by specific “best-of-breed” SaaS products. For example, Accounting Services advertising that they are doing the bookkeeping in well-known cloud accounting platforms etc.

In this post – and since much time has passed since the article of 2010 – I will approach the same idea from a different angle: If a Cloud Provider is around for enough time then they must have developed some business expertise at least in some areas that their customers are active. These areas could be horizontal or vertical. So, what if the cloud provider built some new Business Line to offer advisory services and – mainly for the purposes of this article - Outsourcing Services to their existing customers, thus generating additional revenue from existing clientele.

Let’s see a practical way of doing this: In my experience, a SaaS platform usually offers more functionality than the average customer/consumer is utilizing. The cloud provider sometimes sees this “underutilization” and promotes additional modules or functions to their customers. But, what if the customer does not have a manpower or expertise to utilize what would otherwise be considered as useful functionality and process-improving software? I have seen many cases where the whole idea is just rejected, so neither the customer advances, nor the SaaS vendor achieves cross-selling; a loose-loose scenario. Let’s see a few examples:

An accounting platform may offer some CRM functionality. The vendor promotes this new “module” to their customers and they say “we just don’t know how to do it, we don’t have the manpower, nor are we willing to invest right now”.
A billing platform offers some cash flow functionality, but small-sized businesses do not know what cash flow is or how it is done, or they think that it is something overestimated. So, they are running their business, the usual way, by looking at typical reports and examining their Accounts Receivable, not to exceed a certain limit.

In cases like that, the cloud vendor, may have seen how other similar businesses are operating, what the best practices are and could potentially step-in and offer to their customers not only the software to “do” the function but the actual “doing” of it. In other words, the cloud vendor is generating business for a new Business Line of outsourcing services to the existing SaaS customers. Now, the two examples above are essentially transformed to this:

Let’s sit down together and see what CRM functions you would ideally want to implement and then we shall utilize our own software, using your existing data to come up with the plan and actions. If, for example, the SaaS customer would like to promote new discounts to its good clients, then it could be the cloud vendor’s Outsourcing Department that would a) drill-down to the customer database to find “good customers”, b) prepare the marketing newsletter using internal expertise and c) send the newsletter by existing platform functionality.
Using our expertise we shall study your revenue stream and nature of expenses and we shall propose tactics for cash-flow management. After the tactics are defined and agreed upon, we shall run a bi-monthly refresh of the cash flow so that you will have an early warning in periods of cash balance problems. The small-business manager would get scheduled cash flow reports, just in time to adjust their expenses, loan management etc.

There are many other examples of how SaaS vendors can further assist their customers, assuming of course that the first have actually developed an adequate level of expertise or they are willing to invest in developing by on-boarding new talent. But the main lesson here is that cloud vendors may have an opportunity to transform themselves to something more than “technology suppliers”; I would call it “Holistic Business Support”.

Applying GDPR to SaaS - Data Protection by Design

2018-06-17T18:40:00.000+03:00

General Data Protection Regulation (GDPR) puts on the table a lot of new issues to be taken under consideration and handled by all parties involved in the SaaS market; both SaaS buyers and vendors. In this post, I’d like to focus on the vendor side and discuss a little bit more the issue of Privacy by Design.

SaaS product designers perceive this issue as the general design of the SaaS product in a way that several mechanisms are in place in order to restrict or allow data access and handling by whoever is eligible from the client’s side. Of course, the question of “who” should be answered by clients, when they define their internal processes and map them to SaaS functions. They will define roles and responsibilities, which will result in a mosaic or map of data access rights and user rights. The SaaS platform must be in a position to address this design, preferably through already implemented mechanisms that have been included in the initial design and/or have been long tested in practice. Of course, not-covered requirements may exist and they will need additional development (apart from parametrization) to be met, but in an ideal world they should be minimum in number and minimal in system impact.

Below, I cite a list of basic features that a SaaS platform should have in order to be on the right side of the Privacy by Design “river bank”.

1) Extensive User rights management: Apart from the obvious user rights table where the system administrator defines which user has access to which system features, these rights management should go deeper in the details. If a user has access to a specific function, can he or she utilize the full potential of the system’s information capabilities. If, for example, a typical user has access to issue sales invoices, then is he/she able to also review the customer’s full data sheet? A tax ID field may not be necessary to issue a Credit Invoice, so is this field accessible to the user issuing that Credit Invoice?

2) Role-based access: The system should be able to allow access to “more” or “less” of the data subject’s sensitive or personal data. There may be cases where two users must have access to a data entity (say, the customers’ contracts in a contract management application). But if these users belong to different departments, it is certain that the data that they will need to see are different. The application should be able to “adjust” what is shown to each one, by defining different access levels, by User Role. While a payments officer needs to be able to see the bank account of the data subject, only a higher-level Accounting Manager should be able to edit that field. At the same time, a credit officer should not have any access to this piece of information… This can be a complex map to draw, which, conceptually, could look something like this:

	Data field 1	Data field 2	…	Data field n
Role 1	EDIT	HIDE	…	DISPLAY ONLY
Role 2	EDIT	DISPLAY ONLY	…	EDIT
…	…	…	…	…
Role m	HIDE	EDIT	…	HIDE

3) Row-level access rights: Imagine that data inside a database are organized in spreadsheet-like tables which have rows and columns. What we have discussed in point (2) above generally revolves around the access of users/roles in columns of the Data Subject personal and sensitive data. But what about rows? Can we accept that, if a user has access to the customer file, then he/she has access to all “rows” of that “spreadsheet”? In general, systems and organizations respond with “yes”. But this may not suffice anymore. For example, if a Data Subject decides to activate the “right to restriction” then its personal data should no more be accessible by all or most users in the system. There are many ways to handle this request but generally speaking it is all about restricting the access to a “row” of the “spreadsheet”. This is not a common feature in most applications but it is one that would be particularly useful for the purposes of GDPR. Imagine a mechanism through which you could define that a specific “record” (=row) can be accessed only by users A and B and nobody else in your organization. In many cases that would require some kind of “customization” on behalf of the SaaS vendor, but “Privacy by Design” may imply that this should, from now on, be a built-in feature.

There are many other examples of additional security/restriction requirements that I can think of. But the basic idea is that from now on, just building functionality and granting access per user is not enough. Data Privacy by Design must become an integral part of the application design process and in the next months or years SaaS buyers may see the design inefficiencies of several immature, so to speak, SaaS products emerge.

On the other hand, we should not remain with the notion that this whole thing leaves only some burden on the designer’s shoulders! SaaS buyers should do their own analysis & market research and add a “line” in their system requirements, having to do with the data protection design features that they need. And to do that, they must have documented their requirements, first.

How can a web-based ERP boost your invoicing process

2017-03-14T08:39:00.000+02:00

In an older post (http://goo.gl/jXGmOi) I discussed how web-based or cloud Financial ERP can help you unlock new possibilities for your Business Processes. The basic argument there was that an open system (like a cloud-based system is, by definition) could involve your customers in a specific business process (like sending a Sales Order, posting a comment that needs subsequent action from within your CRM etc.).

The reaction I got from a number of readers was that new best practices could be devised and applied in a very important, so to speak, business process which is of everybody’s interest, big or small: that of invoicing the end-customer. We shouldn’t forget that many small and medium enterprises are focusing their I.T. operations on Accounts Receivable, inside which the invoicing cycle represents a significant part. Therefore, in this post I’d like to focus on this specific issue: how can your invoicing change when you’re using a web-based Financial ERP.

To answer this question, we need to utilize functionality that is inherent to web-based systems (such as openness and accessibility through a web-browser) and point out how such functionality is not present in legacy ERP systems.

Starting from the preparation of the invoice and seeking customer approval, we know that in most cases this is not a frequent process. Usually, accounting prepares and issues the invoice and simply sends it to the customer. If errors are found, then there is some kind of communication (verbal or through email etc.), the issue is resolved and then a credit note and a new, correct, invoice is issued.

But, in the web, it is possible to seek customer’s approval before the actual action of issuing the invoice and posting it to your G/L. A PDF copy could automatically be sent to the customer along with an explanatory email requiring their approval in order to continue with the actual issuing of the invoice; or the customer could be prompted to enter a B2B portal and provide their electronic approval for the invoice in question, even before a PDF equivalent is produced. This will take load off of accounting for the approval process and also minimize errors and credit notes processing in general.

After the invoice has been issued, there is the question of sending it to the customer. This could be done on paper, by enveloping the invoice, sending it through “snail mail” or sending it through email. In both cases, you are not sure whether it has reached its destination and in the case of actual mail, you know that it’ll take a lot of time to reach the recipient and surely you can’t have a return receipt (unless you call on the phone or send another email etc.); let alone the fact that actual printing of the invoice and physical mail cost way to much (studies show that the cost per invoice could reach as high as 7 € per invoice – all costs considered).

But in the “cloud invoicing”, an email could be automatically generated and forwarded to the recipient. What’s more, this email could request from the customer to simply “click there” and declare that the invoice was received, checked and found OK in all of its details; or if it wasn’t found OK, then the customer could immediately inform you of the problem and probably automatically post an “action required” entry in your CRM.

Another idea is that invoices are not even transmitted automatically through email; instead an automated process could inform customers that their invoice is ready to “pick up”. Then they would go into your B2B portal and get the invoice for themselves, probably also get a machine-readable file (e.g. XML) to post into their system as Accounts Payable. Ultimately, your system may log their action of getting the invoice, thus saving you more hassle from checking whether invoices were delivered, managing undelivered messages etc.

Then comes the invoice payment, where a web-based platform could allow the recipient of the invoice to automatically pay the invoice (sure, some kind of interface with the bank is required here!) or, if this is not directly possible, at least have them declare that they have paid, attaching the payment slip or other supporting documentation.

The above show us that web-based or cloud solutions for Accounts Receivable are not just a “technology hype” but are the vehicle through which Business Processes can be redesigned, optimized and streamlined; and the costs pertinent to those business processes can be decreased significantly.

How does web-based ERP enable Growth Hackers in new ways

2016-12-17T09:59:00.001+02:00

Growth hacking unfolds along two parallel lines. The first one is enabling rapid experimentation across marketing channels using new methods that are easy to implement and fast to pay-off (otherwise, they may be abandoned). The second one is engaging customers in several ways in order to keep them in close distance from the organizations sales “reality” and activity. For example, making sure that new products are instantly known in the customer base, interesting news are immediately propagated in the community etc.

In this post I’d like to focus on the latter and discuss how a web-based ERP/CRM integrated solution can decisively assist customer engagement and community building. My intention is to show that SaaS business solutions do not just offer some “technology upgrade” in the organization or solely some cost benefit but can also play a significant role in the growth efforts of the organization.

First of all, we start by noticing that all customer-related information already exist in some kind of (legacy?) ERP: order history, payment behavior etc. Then, a growth hacker needs the functionality that a CRM has to offer in order to complete plans and actions. Typically, one would think that we are discussing about a project of interfacing the ERP with the CRM, so that the CRM has the full history of the customer and therefore be in position to provide “cubes” or “angles” of sales habits, propose opportunities for cross-sales etc. In my opinion this is not enough since a growth hacker’s requirements are volatile and ever-evolving: you can’t just accommodate growth hackers’ needs by simply asking "what kind of information do you want to have travelling across systems?" They simply are not in a position to tell you beforehand; and even if they are, it’s just a matter of time before they come back and ask for something new. Then the project of “interfacing” is opened one more time; in the meantime, because such projects take some time to complete, the window of opportunity – as a growth hacker perceives it – will have been lost.

But let’s look at some examples that a growth hacker may utilize in order to increase customer engagement, assuming that an open, web-based platform is in place (remember, we are discussing the second pylon of growth hacking):

Customers can be invited "in" the web platform, in order to complete business transactions, on-line. For example, to review a sales offer, approve it and therefore instantly ask the vendor (you) to execute the order. More examples like this can be found here: http://goo.gl/VKHQPe

Enhance customer experience through Business Intelligence, offered to them (e.g. last year sales, types of goods, total value etc.).

Send marketing messages - not through the usual marketing newsletter but through the B.I. mentioned above, offered on-line in your systems. Imagine, for example, that when your customers login your web-based platform to review the current status of orders, they are immediately popped-up with personalized messages regarding seasonal discounts, personalized proposals for cross-sales etc.

Blend ERP transactions (e.g. invoice, sales quote etc.) with sales material (e.g. attach a brochure) and marketing actions (e.g. call-to-action inside an e-invoice message)

If one truly believes that these capabilities add value and speed to a growth hacker's job, then maybe the best platform to build on is a web-based ERP, such as a SaaS product. Of course, those who already have a legacy ERP are not left out. They can build web-based front-end systems to enhance the company's extrovert image but the aforementioned issues of interfacing and consolidation of data will always be there.

I envisage a SaaS ERP product with embedded CRM capabilities and “customer login area” in one do-it-all package. And for that, I would be willing to sacrifice some "best of breed" functionality that often enough is just nice-to-have, exotic or overkilling.

Data migration to SaaS

2016-10-16T10:59:00.002+03:00

In the organization’s journey from an on-premise Business Application setup to a Software as a Service one, one of the key factors of success is data migration. Of course, one starts with basic questions like “do I want or need to move to the cloud?”, “Which is the best SaaS solution for my case?”, “Does it address my special requirements?”, “am I content with the reporting/BI capabilities that it offers?” etc. But having answered all of the above, you should take into consideration the data migration issue.

This post will point out some very significant issues around this subject, which you need to address and examine; probably in close co-operation with the SaaS vendor of your choice, before accepting their financial proposal and start the journey.

You might ask, why I am focusing the migration issue to SaaS. Aren’t there always the same questions that must be answered and the same fears that need to be relaxed, regardless of whether we are discussing a new on-premise or in-the-cloud installation? The answer is that there are many cases where SaaS implementations are run like a typical low-cost, semi-automatic on-boarding process, where the vendor may not even be present (or in the same geographical location as you are), instead of a typical “waterfall” type of project where the migration process is a distinct sub-step of the project, it has costs and time associated with it and new code is most likely to be written by both sides. Therefore, in order to succeed in such a low-cost, fast-on-boarding, “mini” project, customers must have a clear vision of what they want to transfer and vendors, from their side, must be certain that they can accommodate these needs with little or no customization.

What kind of data do you wish to move to the new platform?

From all the data sets that you are managing and working with every day, it is very probable that there are some that you don’t really need to migrate to the new platform. There may be pieces of information that exist simply because they were generated or required by the legacy application. For example, could it be that a purchase order was necessary in order to book a vendor’s purchase invoice, while your purchasing process isn’t quite as sophisticated? In that case would you really need to transfer these purchase orders to the new SaaS application?

Another example is that of data with a limited useful life. For example, if you don’t actually have CRM functions in place, then you’d probably not need those old closed Sales Orders that have been invoiced to your customers. If you really need to look at their purchasing habits you could look directly into the invoices database, hence rendering the Sales Orders database unnecessary.

It is very important to answer this question beforehand, because although I can imagine that all systems provide some functionality to upload, say, Customer and SKU records, I am not sure whether they all offer out-of-the-box functionality to upload all the kinds of ERP or CRM kind of transactions that you may require.

What is the depth of the data that will be moved to the new platform?

After having answered the above question, then you need to decide the depth (history) of the data that you will transfer.

The obvious answer in a perfect world would be “everything”. Move, for example, all detailed transactions from the past in the new platform so that the full history of your business events is available on it. The old system will fade out in a second.

But is this achievable? To answer this question you must answer to yourself whether there is adequate knowledge in your organization of the legacy databases that you are moving to the cloud. If not, where can you find and employ external contractors (or the original software vendor) to assist in that task? And how expensive will this be?

Also, will transferring a large amount of legacy data have an impact on the monthly SaaS fee (that is, if your vendor’s pricing scheme includes volume-based pricing)?

An alternative could be to only transfer “some” data, not the entire history of your business transactions. For example, leave transaction history of customers in the old system and start the new one with just beginning balances. In that case the migration task becomes so much easier but you need to answer a new set of questions: Is it acceptable by the Business to have to go back to the old system to look at history details? What will be the cost of keeping the legacy system up and running for many years in the future (and how many is “many”)? Is it acceptable to not have the entire history of the Customer in one transaction ledger and how is it going to affect daily business and customer relations?

Migration technicalities

After having decided what kind of data you will transfer and how “deep” their history will be, you need to clearly define the migration tools and methodology that the SaaS vendor will use. If there are specific technical implications that need to be addressed from your side, you should be aware beforehand. For example:

Ø If there is a need for an additional tool/middleware that must be deployed,

Ø If the migration will be achieved via files exported from the legacy system and whether you are able to produce them (or you need the assistance of a third party) or there is some other kind of technology that your SaaS vendor suggests,

Ø An evaluation of the size to be transferred and whether it can be automatic and unsupervised and can fit in an afternoon of off-hours or it needs a weekend of efforts,

Ø Etc.

Most SaaS vendors will offer out-of-the-box functionality to execute the migration. Is that tool set and methodology enough for your specific needs?

If we look at the issue from the SaaS vendor’s side, then vendors should have a clear methodology and tools for the migration process. In the SaaS world, it is theoretically very easy to on-board and disembark cloud services. What is not easy to do is handle failed migrations not because the application is not good enough but because the data migration issue was not addressed correctly.

What SaaS vendors can do is equip their systems with easy-to-run-and-customize importing tools, so that they can do their part of the job easily and with low risk. Obviously, the old rule of “garbage in, garbage out” still stands, no matter how far applications and systems have gone since the 1970’s (!) but at least SaaS vendors must do all they can to address the issue and, at the end of the day, protect their reputation as “trustworthy partners”.

Is User Interface overrated?

2016-09-03T11:02:00.003+03:00

There is a lot of discussion around User Interface design and best practices. Especially in the area of Software as a Service where systems are accessed through web browsers and therefore any enhancements in web technology, scripting languages and market-driven “best practices” are easier to adopt and put into action. I am putting the term “best practices” inside quotes because I think that sometimes market is driving designers to choices around UI that are controversial to say the least.

For this discussion I will focus on high-end Business Application software and not low-end, narrow-scope programs; let’s have in mind some ERP or CRM applications. Many times, when users look at a SaaS product expect to see a kind of user interface that they are used to by the usual daily exposure they have on the internet, such as social media, news web sites etc. When they see a more “traditional” design approach they tend to characterize the software “old”, “cumbersome” and “not functional”. And all this before they even press a single button!

If the discussion moves further, they will sometimes argue that the system should have been modernized or revamped from its previous version to look more fresh and contemporary. They express these views before having seen how things work inside the application, how entities are connected to each other, how the reporting capabilities of the whole system suit their needs and stop at the first element of examination: the User Interface.

So big is the impact of this discussion, that we see newer systems adapt to the general requirements of the current mid-level management age range, which is the millennials: people that have aged with social media, sites like Facebook, twitter, Messenger for their communication needs etc. That adaptation is their effort to be liked by the today’s buyer (which is in many cases a millennial professional).

Having set the discussion on the general landscape, I pose the question: is the User Interface overrated? Should it be a critical factor for the buyers, in the area of Business Software as a Service? I am putting the cart before the horse and I answer “no”. You see, when we examine a piece of software, we must first examine if it gets the work (that we need) done. In most cases there are small differences in each business process, as it is executed by customer A and B. Sure, the Sales Order Processing is something that most people know and execute in the same way, but the peculiarities of each business tend to infuse small changes in the process or inevitably create variants of it. And it is the SaaS system’s job to try and fit-all-purposes (otherwise it’s “bye-bye multitenancy” and “bye-bye cloud business model”, right?) Therefore, it is possible that the maker of the software has inserted several options and parameters, some selection tick boxes etc. in each screen/view/report that tend to make it somewhat more “packed with information” than you would initially expect. And the discussion begins with something like “the whole thing seems like a bit too much for us…”. The next request is something like “can we redesign some of the screens of the system? We actually don’t need so much overwhelming information” and the whole discussion is derailed from the actual topic of focus (i.e. how good is the system) to a costly, yet irrelevant, effort to making it work “somehow differently”.

My experience over the years (and different technologies used) is that the discussion around User Interface is indeed a valid one, as long as it evolves around ease of use and how objects and entities are connected to each other inside an integrated Business Application. On the flipside, discussions around the design of the screens, the views, the reports and any other design elements of the (web-based) application only makes the final decision harder; and for no apparent reason. At this point, I should mention one funny incident that shows how irrelevant this discussion can sometimes become: In an application I used a small “magnifying lens” icon to show that a specific field had a search function associated with it. A prospect customer that I was giving a presentation to, didn’t like the idea of having a “tennis racket” icon beside the Customer Code field! You get the point? (You would be surprised of how similar a magnifying lens and a tennis racket can look in 16x16 pixel size)

Any kind of user interface will eventually be digested by the users and they will forget how they used to do things. What can’t be overlooked is the problem that a particular system does not fit the purpose and was selected only because it looked fresher, more functional and contemporary.

My advice to buyers, especially the younger ones, is to not “judge by appearances”. It is a very rare case that you will get the functionality that you are looking for from a twitter-like application. Sure, makers will listen to you and try to evolve their User Interface over time, but having a “live-feed” on your production ERP is not what will make your plant work better, nor should it be a decisive factor for your SaaS system decision.

Advanced Customer Ranking techniques in modern ERP

2016-05-29T11:31:00.001+03:00

In this post I will dive into the waters of Customer Ranking techniques and how they can be supported by the existing Small Business ERP that is in use. By the term “supported” I not only mean extracting valuable info as per the customer’s behavior (and thus be able to make decisions about their credit situation) but perhaps also the software being able run the entire process. Of course, such processes do not apply to all kinds of businesses. In this discussion, we assume the business model of a company selling B2B and in credit. Obviously, for a B2C sales model that is being served by, say, an e-shop where all sales are cash, there is no reason to examine low-volume, private customers.

Having clarified the above, I define the “process” as the following series of steps:

· Extract behavioral data from the basic Accounts Receivable (A/R) system. Data like open balances, overdue invoices, maximum overdue time ever recorded, average invoice payment delay and other indexes that the CFO will define.

Feed the system with additional data that do not and cannot exist in a typical A/R system, like published Balance-sheet figures and indexes of the customer under evaluation (turnover, total accounts receivable, open loans from banks etc.)
Additional data may also include objective or subjective views of the Company that concern the Customer, like ranking of the business relationship, so far (good, average, bad), reputation of the Customer in the local market etc.
Having collected all the above data, a mechanism should be in place to examine each of them, one by one (and in combinations, if needed), to produce a final result such as a Customer Ranking Index (1-bad to 10-good) or characterization (1-Unreliable to 5-Reliable) or whatever ranking range the CFO sees fit.
Up to this point, the Customer file has been “characterized” in a good-to-bad range. Now, this ranking can be used to make additional decisions for each customer. Decisions may include:

> Alter the current Credit Limit of the Customer, upwards or downwards (upwards means that good customer behavior is rewarded; this can be used also as a CRM function: how do you communicate this increase of the credit limit to the customer? Through an integrated CRM function, perhaps? See here: http://tchristidis.blogspot.com/2010/05/crm-integrated-with-your-core-business.html)

> Change the Credit Terms with which you do business with that customer (e.g. for a low-ranked customer, you may want to ask for a larger down payment or even 100% down, before goods shipment)

> Advance the customer to a pool of “best” (or “worse”) clients, where your CRM of collections process is different, less or more strict.

Now, in order to automate the process as much as possible, especially the last part, the “decision-making” and “making it happen” functionality, I think that the best way to achieve this, is through a Ranking System that is integrated with the rest of the general A/R system. You see, if the Decision-making process is detached from the customer files and parameters, then all you can do is get some kind of “report” from the Ranking System, examine it and then apply the suggested changes manually in the A/R module of your ERP. If the Ranking System was integrated with the ERP then the application of Changes on the actual Customer Records would be one click away (with the possible addition for some higher-authority review-and-approve process/workflow, too).

Once more it is proven that a fundamental business process such the customer examination and ranking can be better served by an integrated system that combines process-specific functionality (the Ranking System) with general ERP objects (=Customer, Invoices etc.) and parameters (=Credit Terms etc.). Although a large ERP may provide this functionality out-of-the-box, we have yet to see smaller products (and especially Cloud SaaS) offer something similar. SMB Cloud Accounting Platforms are struggling for market share and each of them has something less or more to offer in specific areas. But that specific Customer Ranking process and module is something that is missing from the market.

The Invoicing cycle gone web. The tangible benefits

2016-04-10T10:44:00.000+03:00

In this post (http://goo.gl/DhcEZp) I have focused on the Invoicing Cycle and the paradigm shift that takes place when the enterprise utilizes a web-based ERP. I showed how specific business process steps within that cycle can be changed in order to invite customers “in”; make them part of the process instead of just giving them “data” or – worst yet – just an invoice at the end of the cycle.

In this post I will continue discussing the same example and calculate tangible benefits, for each of the steps of the process. You’d better first go through the previous post to understand how each step is altered in a web-enabled ERP and then make the comparison with the numbers below.

Let’s first assume that the employee that deals with these matters costs about 1.500 € per month for the company. Divided by 22 days of work per month and 8 hours per day, this gives us an hourly cost of 9 €. All calculations below are based on this number and extrapolated to a full year. This will give the reader the immediate comparison of the cost saving against the yearly cost of a new web-based ERP. My point is to show that, at the end of the day, the cost of the web-based ERP, if this is a cloud Software as a Service solution, can be financed through the mere cost savings of the Invoicing process. Let’s see if the numbers compute!

Step	Web-based ERP	How hours are saved	Hours saved, (monthly)	Cost savings (yearly)
Browsing of inventories and prices & Order placement	Enhanced by an integrated B2B sales portal inside the main system	Customers do their own browsing and purchase orders	2 * 22 = 44	4.752,00
Order confirmation	Automated notifications. Issuing of a pro-forma invoice for the customer’s acceptance. Close the process from within a web-based workflow system.	Less telephone calls. All orders are confirmed prior to issuing an invoice	0,5 * 22 = 11	1.188,00
Picking and shipment	Internal process. No major differences here.		0	0
Order tracking	Enhanced by an integrated B2B sales portal inside the main system. Invoice sent through email for faster processing by the customer.	Less telephone calls. Customers browse their status, when they need	0,2 * 22 = 4,4	475,00
Goods delivery	Only dispatch note received with package. Electronic equivalent of it may have been sent in previous step.	Electronic invoice zeroes time spent for printing, enveloping etc. More cost cutting by printing expenditure etc.	1 * 22 = 22	2.376,00
Order acceptance	Powered by a workflow inside the web-based system. Clock starts ticking for the invoice payment…	Formal order acceptance can result in decreasing overdue Accounts Receivable	0,5 * 22 = 11	1.188,00
Invoice payment	Customer “signals” invoice payment through automated workflow.	Accounting books the receipt but A/R employee is disengaged from this process!	1 * 22 = 22	2.376,00
Collections process	Through an integrated Collections system. Web technology can offer automated emails, SMS or even customer portal with capabilities of self-service by the customer.	Significant decrease in Collections actions	1 * 22 = 22	2.376,00
TOTAL (per year):				14.731,00

Notice that the above estimates indicate that the Customer Orders dept. will save almost one (1) FTE (Full time equivalent) by enhancing this process. Now, if you translate the numbers in people, you must certainly take into consideration that each employee must have a replacement in cases of sickness, leave of absence etc. It is evident that, if a job takes one FTE to be done, then the organization cannot have ONLY ONE FTE in place!

From the above, I think it becomes obvious that theoretical enhancements in just one business process can fuel (finance) the purchase of a cloud-based, Software as a Service ERP solution, at least for the small and medium enterprise. Of course, that is not to say that the mere introduction of such a system will improve the business processes! It takes some restructuring plus a road map to change. Although this is another discussion, outside the software itself, it might be a significant factor to take into consideration when selecting your new cloud vendor: Is everybody willing (and able) to guide you through this road map? Or will you need additional consulting assistance (=professional services) to make your way through?

The Invoicing cycle

2016-02-06T10:01:00.001+02:00

In an older post (http://goo.gl/jXGmOi) I have discussed the general benefits that a cloud ERP could bring to the enterprise, even to the SMB space. I have given some examples of specific business functions and how they can be transformed or at least assisted by the web technology that the cloud ERP inevitably brings with it.

In this post I will focus more on one specific business process, that of the customer order placement and order fulfillment and show that not only is a cloud platform (such as a SaaS product) able to optimize the whole process but also enhance customer experience and finally bring tangible benefits to the enterprise, such as faster invoice payment and reduction of open receivables.

Let’s look at the following table which illustrates a typical order placement/order fulfillment process. In separate columns I show how the detailed steps are completed in a legacy in-premise, “behind-closed-doors” ERP and how the process is changed by an extrovert web-based system.

Step	Traditional ERP	Web-based ERP
Browsing of inventories and prices	Printed catalogues, telephone calls, sales rep calls, B2B sales portal (if it exists) (*)	All traditional methods plus through an integrated B2B sales portal inside the main system. See here for more information: http://goo.gl/jw1qRi
Order placement	Telephone calls, sales rep calls, B2B sales portal (*)	Enhanced by an integrated B2B sales portal inside the main system
Order confirmation	Telephone calls, or none	Automated notifications. Issuing of a pro-forma invoice for the customer’s acceptance. Close the process from within a web-based workflow system (Customer accepts the charges and there is a digital signature for that)
Picking and shipment	Internal process. No major differences here. For Supply Chain enhancements, we’ll talk another time!
Order tracking	B2B sales portal (*)	Enhanced by an integrated B2B sales portal inside the main system. Invoice sent through email for faster processing by the customer.
Goods delivery	Invoice and any other documents received with package	Only dispatch note received with package. Electronic equivalent of it may have been sent in previous step.
Order acceptance	No process today	Powered by a workflow inside the web-based system. Clock starts ticking for the invoice payment…
Invoice payment	Customer pays and vendor sees the payment in the bank statement or is not notified at all! Accounting is browsing through the statement and is trying to match payments with invoices	Customer “signals” invoice payment through automated workflow.
Collections process	Traditional calls, letters, sales rep visits etc. Letters probably produced by the ERP, if functionality exists.	Through an integrated Collections system. Web technology can offer automated emails, SMS or even customer portal with capabilities of self-service by the customer.

(*) at this step, an additional B2B sales portal means additional costs, duplication of data, interfaces “hassle”, maintenance costs (software, I.T. salaried costs etc.). Most SMB’s cannot bear such costs. For B2C sales, this can be done through the “e-shop”, if it exists.

From the above, I think it’s obvious how the whole process can be optimized, shortened in time and require less interaction between the parties. In that same context I think that the whole customer experience is enhanced and this ultimately may result in more customers, more loyalty and bigger sales figures.

We’ll discuss more tangible benefits in a future post. Stay tuned…

To email or not to email. That is the question

2015-12-15T18:00:00.000+02:00

We are all accustomed to receiving emails from automated services, such as our social media accounts, mailing lists that we’ve opted-in, e-shops that want to keep us updated about their new offers etc. This activity may cause an avalanche or overload of activity in our inbox. I guess each of us has pondered over overwhelming inbox traffic and has probably decided to opt-out from some services…

For some of us, there is also another source of inbox traffic: automated emails sent by our core business application (such as a CRM, ERP and the like). More often than not, applications send automated emails to keep us updated about recent events that are of interest to us and have been logged inside each application. For example, a workflow requires our attention or approval to move to the next level, our supervisor has approved our leave of absence etc. Apart from overloading our inbox, an additional problem is that new emails “ring our desktop bell” with a sound or visual sign that instantly takes our focus from the task at hand. The problem is that when you see that you’ve got new email, you can’t know whether it is truly important or not until you switch to your email window and check it. But the focus has already been lost! Some will argue that you don’t need to check your email every time that you hear or see the “new email” sign; do it every couple of hours or so. But then, you may miss something important!

There is no doubt that we should somehow be kept up to date for these events and sending a preconfigured email in our inbox is one way to do it. What I’d like to explore in this post is whether alternative ways to be informed are preferable to email.

Popping up messages from within the application: Instead of the application sending an email, it can popup a message for you, on your desktop. That way, you will be instantly informed of important updates as long as you are logged on to the application. Of course, some would see this as a drawback – why do I have to be logged in the application to see the notifications that I’m supposed to? That way, I will probably lose some important update that requires immediate action exactly because I was not logged in. On the other hand, how often is there an automated email that requires your immediate attention? How often is it just a derail from what you’ve already been doing? Popup messages are a good alternative because you receive notification if you are already working in the same context and that notification will probably not be undesired. For example, if you are working on your accounting, it is not out of context to be asked to provide an approval for an invoice payment. If you are reviewing staff records on your HR, it is not a derailment to be asked to review one more applications for leave of absence and so on.

After all, for really important updates there is always the good old email. Only, this time, it will be sent to you by a human who will most likely explain why it is so important and so-to-speak “persuade” you that it needs your immediate action.

I am ready to admit that there is no golden rule to decide for each process whether email or popups are the best solution for each case and that’s why I’d like to see each user having the option to select between “email” and “popup” for each kind of notification that his/her applications support. Imagine a kind of control center where the user would see all the available notifications that the application has to offer and beside each, a selection between “email” and “popup”.

Ability to “mute” notifications: Regardless of the debate of email vs popup message, I would find it very useful if users could set themselves “unavailable” for automated notifications, email or any other kind. That way, one could temporarily isolate oneself, when there is some important work to be done and does not wish any interruptions. Notifications of any kind can be set on hold and released to the users when they make themselves available again. Emails will come pouring in and popups will fill their desktops; only this time the user will have allocated the time to read through and process each of them, without being pushed to act immediately, without experiencing that annoying every-ten-minute notification and consequently without raising his/her anxiety levels. Because that is what it is all about: repeated interruptions prevent you from devoting yourself to the task at hand and therefore making your work more difficult, making you less productive and, at the end of the day, raising anxiety levels.

In the world of B2C or B2B sales portals, news web sites and a whole lot more, Customer Experience is something that is widely discussed and focused on. Part of it is eliminating all these features or functions that can potentially drive users away. A core-business SaaS product should be no different in that area; especially if we take into account that its users usually remain logged on for quite some time, every time.

B2B sales portal and SaaS

2015-11-19T15:57:00.000+02:00

In an older post (here http://goo.gl/jXGmOi), I scratched the surface of the idea that the cloud ERP could also serve B2B sales, by enabling the enterprise (SaaS customer) to invite its own customers in a “B2B sales portal”. I don’t see this portal as a substitute of the e-shop for B2C sales; nor do I find the idea of the SMB developing a separate system particularly interesting. Implementing a new, separate B2B sales system and having it interface with the cloud ERP would not be a cost-effective solution, or a sustainable one in terms of additional and recurring costs.

Instead, I propose that the selected cloud ERP platform could or should offer a relevant offering, out-of-box or, at least, an integrated solution for B2B sales. It is exactly the right point to build extrovert functionality, intended to automate a business process where the customer is a key stakeholder. You see, the cloud ERP is already “there” (meaning that it is exposed to the internet) and already has all the necessary information that is required to build, circulate and fulfill a Customer Order. You have your customer records, your warehouse items and actual inventory and the billing module to issue the final invoice to the customer.

Of course, B2B customers may have additional needs or requirements, compared to occasional B2C customers, who will usually register, order and finalize their order by supplying a credit card. It is exactly this additional functionality that interests me and below I make an attempt to outline some significant parts of it but, more importantly, to show why an external e-shop-like tool would not fit the purpose.

Typical B2B customers would probably not be asked to pay cash (through a credit card or PayPal, that is) for each and every one of their orders. In these cases, there should also be the possibility of reviewing one’s current balance or get notifications in case of balance excess or other conditions.
Frequent customers, as we can assume that B2B customers are, may need a kind of workflow to be followed for each order. For example:

Ø What is to happen if there is not enough inventory for the requested item?

Ø Should the supplier keep a backorder?

Ø Can there be special discount campaigns for specific customers and how are they notified upon their login on the system?

Ø Etc.

If the vendor also executes the logistics of the transaction and assuming that the delivery process takes more than a few hours, then the end customer can get email or other notifications about the status of the delivery, while in a typical e-shop customers receive – at best – an order-tracking number and they have to tap in the logistics web portal to see it.
The B2B solution must have the option to export machine-readable data concerning the sales invoice or other data necessary for feeding the receiving system. In other words, fully automate the Electronic Invoicing Cycle, instead of just sending the PDF of the invoice.
Integrated with the main cycle of order and order fulfillment, the cloud ERP could also offer other functionality such as ticketing system for issues/disputes resolving etc.

My point is that, if your company relies heavily on B2B or “wholesale” sales, then the B2B Sales Portal is a necessary component of your software stack. And the best place to build it is on your cloud ERP. Or, to make a stronger point, the B2B module could be one of the decisive factors the next time you execute the software selection process for the ERP.

I.T. departments can become profit centers for the enterprise

2015-09-09T16:29:00.001+03:00

When customers are looking into a SaaS offering, they usually overlook the infrastructure that the software is running on; and for good reason: They don’t care in which platform the software runs, what kind of servers it runs on etc. as long as it performs as it is expected to. There are some SaaS vendors that run their service from owned infrastructure and some others that also receive IaaS or PaaS services from third party providers.

Which leads me to the following thought: Anyone (any I.T dept., that is) with an infrastructure robust enough to offer a good Service Level, can potentially offer and host SaaS services for new customers, outside the strict boundaries of the enterprise.

Therefore, *any* I.T. dept. of some magnitude and organization can become a profit center for the enterprise that it belongs to. This is a new way of looking at things, especially trying to leverage the costs that an internal I.T. department incurs to the general P&L. Of course, a dedicated I.T. department cannot be developed beyond a certain point and compete with SaaS vendors that were built top-to-bottom to offer such Cloud Services, but this is not the objective. The objective is to utilize existing infrastructure, know-how and support manpower for external customers or cooperators in order to generate a new revenue stream, from a company division that is usually perceived as a traditional Cost Center.

Let’s imagine, for example, a central I.T. hub of a corporation that has built a private cloud to host Business Applications that are offered to its small subsidiaries around the country and beyond (like, say, small-business ERP). One reasonable question that can be raised is “why not offer the same software to other, similar businesses that may be outside our subsidiary structure? For example, independent dealers that offer the same products as we do”. There is a high probability that such an endeavor is successful, for many reasons, the CIO and CEO might think:

These independent dealers do the same work as our subsidiaries, therefore what is good for us, must be good for them, too. Any customizations or parametrization of the software will probably fit them, too.
Our know-how on resolving business issues can be used for these “external customers”, too. We can offer them this knowledge as an add-on service.
The working hours will probably be the same, therefore we can support them in the same time frame that we support our own network. We shall use existing support staff and increase only as the business expands. Any scheduled down-time will not a problem for them as it is not a problem for us, either.
If these external customers are also our business customers (apart from being I.T. customers), then we can build new functionality and automations between us and them, thus enhancing automation, increasing performance and reducing costs.

Technology is an enabler. If we look at things from the Application side then a carefully design application can be used from many different tenants at the same time. Looking at things from the infrastructure side, we may agree that there are cases where corporate server “horsepower” is sometimes over-budgeted and underutilized and therefore can be offered to other “tenants” too. In conclusion, offering existing applications to a wider range of customers (i.e. other than the “internal” customers) is surely technically feasible. It just needs the validation of the rest of the business stake-holders, but that’s another discussion that has to be taken into the Board Room.

Advanced Collections functionality inside your Accounting Software

2015-08-14T13:08:00.001+03:00

From years of experience in Retail Banking systems, I have seen that one crucial business process is the Collections Process; the function through which the banking institution tries to collect overdue claims from its customers, while keeping the process simple, automated and with a high return rate. Obviously, there is a necessity for a System to support this process. Over the years, many software vendors have focused on that area, developing Collections-specific software and offering it “on the side” of the core banking system. Carefully designed and monitored collections processes have been implemented in banks, then in insurance companies and then in other areas of the economy, too.

But, I have yet to see small and medium sized businesses implement well-documented Collections processes, to manage their Accounts Receivable; especially in cases where sales are usually done “on credit” or the business model is not “cash-and-carry”.

In many cases, we see A/R officers or line managers using traditional methods to a) identify and b) execute a collection action. If we are talking about a typical SMB with a small ERP or accounting software in place, they are usually using “open balance” or “overdue” reports to identify bad customers and then they are picking up the phone to call them and, maybe, get a promise for payment.

But, implementing new, solid and automated Collections processes in the typical SMB may have the same cost-cutting and general efficiency effects that it has for the large organizations, too. Perhaps small business owners need some consulting to better understand what this is all about and what are the tangible benefits they will enjoy in the long-run, but from where I stand, I wanted to take a closer look at what such a system might look like and why it should be integrated with the existing Accounting / Accounts Receivable system. And this is what I found:

It is in the Accounts Receivable module where you issue your invoices and keep the customers’ balances. Therefore, if you go one step further, you can develop Credit Terms policies and track them through your A/R system. When customer payments do not come in time, you need an automated system to classify your receivables based on their age and amount. Each customer must be characterized with the “worst” Open Item identification that their invoices have.
The receivables need to be re-examined every day to see if their classification has changed (and thus, the customer’s classification has changed).
All overdue customers must be reported in a “worst-first” order of appearance so that designated people (users) take some action.
Regarding the action itself, the system must be able to propose which action is best suited for each case, based on customer classification and previous history. E.g. there is no point in calling back a bad customer which has denied payment; you’d better send a written notice and after that, proceed to legal actions. This and many more examples should be entered in a model database so that the system can propose “what to do next” for each case.
For each action taken in the previous step, there may be a follow-up action required. Also, you might want to assign this follow-up action to a designated person, so that each officer takes ownership of a case (and you be able to monitor their performance)
Now, because telephone is not the only way to communicate, a useful addition to the Collections system would be the ability to send bulk letters, emails and text messages. Sure, there are a lot of services out there that are up to the task, but all of them are expecting you to prepare a list of people to send to. You would probably use a spreadsheet to put all of your bad customers, classify them and then produce sub-lists, directed to the email service, the SMS service and the printing service providers… Too much trouble, when your A/R-Collections-CRM system could do it automatically, for you. Imagine spending just a few minutes of your time just reviewing ready-made lists and then act on them, with a push of button…
When Credit Terms have been implemented in your organization, these can be integrated with the Collections process so that bad customers can be downgraded to a “worse” Credit Policy, while good customers can be upgraded. You see, the objective of the Collections Process is not only to collect the overdue amounts but also decrease the probability of the customer generating delays again in the future.
When you are in a discussion with an old customer about new business, you need to be able to see their old behavior; this is surely a decision factor while discussing the new agreement. And what better source of information than your Collections module where previous history and behavior is (should be) recorded. In other words, the collections module purpose should not only be to enable the daily operations but also to collect “intelligence” about each customer, for any future use.

As a fan of integrated systems (the best-of-breed logic is of course understandable but I doubt of its cost-benefit for small and medium sized businesses), it is my opinion that A/R and CRM contain most of the information that one needs to build a solid Collections process and a Collections subsystem, closely tied with the rest of the Business Application software that you use. The benefits of such a new project will be enjoyed fast enough, especially in troubled markets.

Social Business Application Software and its correlation with SaaS

2015-05-24T11:26:00.000+03:00

In this time and age where Social Media have become an integral part of our lives (private and professional), there is an ongoing discussion about Social ERP (sERP), social CRM (sCRM) and other “s-prefixed” systems. In this post I’d like to contribute my own definition of the “Social” tag and discuss how this could be served by web-based systems and even enhanced by SaaS communities (I use the term “SaaS communities” to show that users working on a cloud Service (public or private) form a new “closed” community which – like any other community – chooses to open up to certain other teams (a.k.a. other users) under certain restrictions and rules (a.k.a. authorizations).

I see three different uses of Social-like tools and rationale, which I list below in ascending order of “users involved”.

The first is the usage of social tools and methodologies (the terms “social” and “methodologies” seem so remote to each other, don’t they!) among users that belong to the same organization. The objective here is to utilize social user interface and tools to keep colleagues engaged and assist or enhance collaboration. Let’s see a few examples:

o The existence of a “corporate timeline” keeps all employees up-to-date on corporate issues (just like the timeline of Facebook which keeps you in touch with your social friends). This corporate timeline may also include important messages from the organization heads or HR department etc.

o Because this social environment operates inside the core business application, we can easily imagine distinct timelines per business event (for example a Customer Order can include the discussion between departments on how to go about a problem that occurred with that specific order or a Cash Flow Analysis can include comments from the CFO indicating problems found and requests to rectify them etc.).

o The function of “nudging” a co-worker or send an instant message (without overloading each other’s email) can increase response times for trivial issues.

The second use is the expansion of the social tools in the entire SaaS community where users can interact even if they don’t belong to the same organization. In this case, sharing of corporate data will be extremely limited (since SaaS tenants may have no relation with each other or even be competitors) In this case, I see social interaction more in terms of knowledge around the SaaS environment, in order to

o Discuss non-business-specific issues, like certain functions of the SaaS service

o Request for community support

o Broadcasting a new bug that was just discovered

o etc.

This is normally done outside the Service, usually inside Twitter. But imagine being able to use this social functionality from within the Service and share images, screen shots etc.; getting help from other members of the community and then conveying the new knowledge to your co-workers. (Let alone the fact that public social media may have been disallowed from your corporate network, thus leaving twitter and the like out of your reach, from 9 to 5).

The third is the invitation of external users inside the business process that is materialized by the “s-System”. External users are primarily customers (but surely not limited to this category). The s-System invites external users to engage in the Business Process, first by being notified in any status change of the Process that concerns them and then by allowing them to contribute their input, data or comments to that Process.

For example, the Process of compiling a sales quote from a sCRM system or the fulfillment of a Sales Orders inside a sERP could engage end-customers so as to keep them notified about the current status of the order, allowing them to make comments, express their concern about delays or allowing them to request last-minute changes. Of course, if external users are “invited” in the Process, then care must be taken so as to disclose only the part of information that is intended for them.

The trend of enriching business applications with social features is just beginning but I think that this trend will continue and will even lead to a redesign of the classic CRM/ERP/etc. applications, as we know them today. The main reason is that social networking is becoming part of our everyday life and we have come to expect that functionality like this must “surround” us. It is surrounding us with the wide expansion of public WIFI and smart(er) phones and so it is only logical to expect that we will ask it to come into our professional lives, too. And this expectation will grow even larger as newer generations (generation Y) populates the global workforce. Application designers cannot overlook that trend and must be prepared to react.

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

2015-03-13T09:10:00.002+02:00

In the previous post I commented on some attributes or characteristics of Software as a Service that may assist organizations shift to an ITSM delivery model. The general point of entry is that SaaS eliminates many of the technology headaches that the organization may be facing, thus giving space to more customer-oriented processes to be developed, rather than just managing the technology stack. And in this discussion, the corporate user may also be considered as an “internal customer”.

In this post, I continue enumerating some more aspects that change shape and how SaaS can assist in that transformation.

One-off or ad-hoc vs Repeatable and Accountable action: Since ITSM focuses on Process rather than Technology, the formulation of repeatable action plans for any given circumstance and the accountability that must come with it is very important. If the “mission” of each corporate department comes down to “service the customer”, then methodologies must provide for pre-designed or pre-configured procedures for any given circumstance. SaaS and the cloud can assist in the effort by providing an integrated working environment for all users, sharing of information to everyone that needs to have it and access 24/7 so that problems are tackled without time or geographical constraints. Also, assuming that SaaS is not heavily customized (a logical assumption is most cases) then procedures are well-defined and as strict as they should be, as opposed to customized software with lots of ad-hoc back-doors and probable security problems. Finally, it is not a scarce case where in-house custom-made software fails to perform adequately in the area of user accountability and error logging, while most high-end SaaS products can be expected to embed such features.
Informal vs formal processes, best practices: In the same spirit as above, the ITSM-focused organization must have already built formal process for each case (many of them are using ISO or other standards) and try to apply best practices for each business process. In some cases, consultants have been employed to design such processes. The task can become quite difficult when the underlying software does not help. We are not strangers to the fact that many times custom software has hard-coded processes that specific users or officers have designed in the past, with little or no ability to upgrade and/or redesign. In the opposite side, we can expect a SaaS product to incorporate best practices, worked out by studying a number of different applications/business types, often designed by a team of subject matter experts. After all, SaaS vendors try to avoid by all means hard-coding less-than-perfect processes and workflows as this would mean that their product would fit a less-than-adequate number of customers. And when time comes for changes and adjustments we would expect that the extensive parametrization of a SaaS product would make things much easier; probably solving a number of problems with no coding or “change requests”.
Focus on Operations metrics vs focus on Service Delivery: Traditional IT departments focus on managing the technology components that work inside or for the organization. When this is translated into metrics, they tend to use technology metrics such as server uptime, database maintenance windows etc. When the entire IT function shifts to ITSM, then the questions become different: Do we provide good service to internal and external customers? Are business processes adequately served/supported by the technology components? SaaS is in the same page here, since its mission is not only to “mechanize” existing business processes (or replace an old legacy system) but also assist the organization to quickly adapt its software to new business needs while avoiding investing to software customization (which is the long run will result to low ROI and high investment figures).

In this entire process, the role of IT managers or CIOs also shifts to a new level. They must no longer stick to their traditional technology role but be part of the business design and development. In that process, they must be sponsored by the CEO and “leveled up” to the C-suite. But that’s another interesting story, which we’ll discuss in a future post.

Software as a Service (seen as a cloud technology offering and not just as an invoicing method – aka “leasing”) can assist organizations achieve a shift to ITSM. That is not to say that SaaS is the only way to go, just that it incorporates several attributes that point to the “service delivery” direction, leaving technology more and more out of the picture. And for that reason, extrovert organizations that seek a new approach to their customers and service delivery should have a second look, when the time comes for software upgrade; towards SaaS.

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

2015-01-25T10:16:00.001+02:00

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…

How cloud and SaaS can enhance I.T. agility

2014-11-10T13:17:00.000+02:00

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.

IT chargeback/showback and SaaS

2014-05-14T20:01:00.000+03:00

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

Comparison of Private and Public clouds

2014-04-18T12:03:00.001+03:00

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:

Issue	Private Cloud	Public Cloud
Security	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	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.
Predictability	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.
Agility	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.
Customization	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.
Governance	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…

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

2014-02-16T10:38:00.000+02:00

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.

SaaS: An opportunity for closer cooperation

2014-01-05T10:47:00.003+02:00

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!

Reverse SLA

2013-11-12T15:43:00.001+02:00

The relationships between customers and providers in the cloud business are generally governed by the Service Level Agreement or SLA. In a previous post I made the point that a really “tough” SLA is probably not the “holy grail” of the cloud business, which every customer should be looking for. In this post I will continue the same line of thought, focusing this time in the impact that a strict SLA has on the customer organization itself. For this purpose, I will use the term “Reverse SLA”.

Although Reverse SLA is not a widely used term, I would define it like this: the mirror in which all vendor commitments are reflected and produce an image of the customer’s obligations in terms of response and organization, in order to smoothly receive any service that is provisioned by the SLA.

In this post I shall not analyze what the usual KPI’s are (lots of documentation for this on the net) but I intend to give some examples of some customer-side issues or challenges, which may prevent the smooth execution of an SLA. I will list the most frequent customer requirements and explain the implication that these requirements may have on that same customer’s organization. If you are thinking about using cloud services, when you are done reading this post you will hopefully have reached a good level of understanding about the impact that cloud adoption will have on your organization. You will also have understood that cloud services are not only about vendor meeting a series of obligations but also about your own part and role in the whole process.

A. Service availability and hours

The SLA includes the working hours that the service is available (typically, lots of “nines”) but also the time frame that the provider can/should serve customer requests. Focusing on the latter, this frame may vary depending on criticality (bugs, change requests, etc.). This issue sometimes becomes very important when the customer does not operate in usual office hours but spans beyond the normal hours of the vendor.

In that context, it is only about the vendor having the proper mechanism in place to process such requests but also about the customer having to be prepared to get feedback and finally assist the vendor in resolving the issue. Here are some examples that may prove problematic on the customer side:

· In each case of issue or problem there has to be a departmental or overall representative (or manager) to be contacted by the vendor and in general be the communication hub between the two parties. If the service spans beyond normal hours then the customer has to nominate a person who will be available during all that time span.

· Also, it must be clear that this designated person should be engaged in all circumstances and that it is not normal for end users to directly call the support center, trying to resolve the issue through non-authorized channels or procedures. In such cases, the vendor may refuse or declare inability to respond.

· If the issue requires some user action, then a contact person must be included in the request. Otherwise, this may result to a resolved issue that the customer’s organization will not able to digest (e.g. test a new patch etc.)

· Provide sufficient access to the vendor mechanics to look at the issue and go as far and as deep as they need to (without compromising in-house security, of course)

B. Service throughput

It is not only a matter of whether the vendor can deliver. It is also a matter of “how much” can they deliver in the unit of time. Some customers may have increased demand on this “service throughput”. But what is the customer doing to ensure that all this throughput is absorbed by its organization, as fast as it is delivered? For example:

· There must be adequate resources on the customer side to perform User Acceptance Tests and the infrastructure to schedule, agree and monitor delivery schedules. This, among other cases in this post, is a good example of why the customer can’t do without a designated I.T. department or – at least – person in its organization.

· In special cases where the throughput or availability needs to be higher than usual, the vendor must be informed beforehand in order to be given time to organize and be prepared for that special occasion. But the same applies to the customer’s internal organization.

C. Response times

The response times may vary depending on type of request. For example for bug-type of requests the response may be just a few hours and for Change Requests it could be days. Many times customers are pushing very hard to minimize all these times/metrics. But they must be able to respond to the issues as fast as they are asking the vendor to. There is no meaning in having the vendor respond “fast” when you don’t have the structure in place to receive the outcome of this task. Otherwise, you run the risk of:

· Receiving extra charges for extra-hours service that you received without really needing it.

· A problematic case that was resolved fast enough but you weren’t “there” to accept it.

· A bug that was declared solved but you didn’t re-test and accept it in your Production Environment (with potentially disastrous effects)

D. Escalation procedures

It is probable that not all issues are resolved through the “service desk”. They may require escalation to higher authority, some management decision etc. Customers are right to ask from vendors to define such procedures. But they also need to have similar processes (and people) in place in their organization, too. Otherwise, the escalation process will not work and will most probably end up in a “vicious cycle” of “who’s to blame?”

E. Security guidelines

This is a very well-known issue that customers are pushing vendors to perform. And they are right! But what are they doing in order to meet the same standards that they are asking from the vendor and – if what they’re doing is not enough – then who’s to blame in case of problem? A few examples:

· Are the customer’s Personal Computers equipped with up-to-date antivirus programs that ensure proper function? If not, then is the Service Desk responsible to remotely resolve a communication issue between the client and the server?

· Is the operating system and patches installed according to the vendor initial or current requirements? Otherwise the vendor cannot be held responsible for the user’s PC not performing correctly.

· Is the customer using the designated and tested/recommended web browsers that the vendor product supports?

I’m making the case that it is not just a matter of provider capability to “deliver” but also a matter of the customer meeting the requirements that automatically arise by the provider’s actions to “deliver” and its ability to digest the input that is created from the execution of the SLA. Also, it is now evident that abiding by the SLA requires that adequate staffing and expertise are in place, on behalf of the customer, otherwise the provider can’t be expected to “perform” above the level that the customer can “absorb”. In other words, it is probable that tough negotiation results in an SLA that can’t be monitored by the customer and, as such, has no real meaning or benefit for the customer.

The binding nature of SLA

2013-10-21T11:36:00.000+03:00

The cloud business brings some very interesting and unique characteristics in the way customers and vendors are engaging: For the first time in computer history massive amounts of data are processed and stored outside the physical boundaries of the enterprise (its LAN or WAN). Also, vendor companies can reside thousand miles away from the customer premises and they are run by people that most probably the customer will never meet in person or maybe even talk on the phone.

These unique characteristics make the customer/vendor relationship very interesting and also somewhat difficult to describe. Such relations are typically governed by the Service Level Agreement (SLA) which the customer signs or in some cases just “accepts” with the click of a button on the web page of the cloud service they’re subscribing to.

Many times there is no option to “discuss” or “negotiate” such a document the way an “end-user license agreement” was negotiated in the past, when a piece of software was “sold”. Customer may or may not accept the terms (and move on to the next available choice). This very fact builds pressure on customers to accept a document that perhaps it does not find them exactly in accordance and also to vendors to come up with a collection of technical and legal terms that are “safe” for them but also not “intimidating” for the customers: something that can persuade customers to get on board the service instead of driving them away. These two “opposite forces” tend to reach some kind of equilibrium and this post investigates what this equilibrium point is.

One way to describe the customer/vendor relationship is to have a very detailed SLA, defining all possible outages or out-of-service conditions and that’s what many customers are looking for. But I would argue that the more detailed an SLA is, the more safe it may become for the vendor, leaving the customer uncovered (or, better, inadequately covered) in some cases. How can this be? Here is an example: The customer asks for specific provisions when there is data loss in the cloud service. This raises the question of what will the vendor’s obligation be for damage caused by such data loss? Obviously, it can’t be a number many times larger than the yearly fee that the vendor collects, otherwise the vendor has built a high-risk business, which makes no sense. And then, it can’t be a number too low, otherwise the customer doesn’t have adequate insurance for their data. In the hypothetical case where the SLA does not provide anything for this case, then the customer might ask for astronomical figures making the case that the data loss has seriously damaged its business. The vendor, on the other hand, could argue that they owe nothing to the customer, since the SLA did not include any specific clauses. A real mess in the customer/vendor relationship, I’m sure, and a real deal-breaker. But what is the mitigation for such risks? Perhaps a very detailed SLA that includes specific provisions for each distinct case? I wouldn’t agree that fast! You see, analyzing every little detail will work not only for the customer’s benefit but also for the vendor’s. The vendor might use these clauses to limit their risks to an absolute minimum. So, it is probable that in the above example of data loss, the vendor is obliged to offer some discount or re-imbursement on the next invoicing period and they are “off the hook”, that easy.

The point here is the following: A very detailed SLA covering all possible cases of risk, quantifying each and every small detail is not the “holy grail” of customer/vendor relationship that all customers should seek. Instead, customers should also look for other ways to make sure that their selection of vendor is correct, like investigating the “word of mouth”, asking for real-life references, and in general performing due diligence on the vendor selection process.

Mobile is the future

2013-10-05T10:20:00.001+03:00

One of the many advantages of web applications (Software as a Service – SaaS applications are the best example here) is their “portability”. Before the rise of business web applications one had to tap in a corporate server using difficult to understand or use technologies like “remote desktop” etc., to gain access to corporate data and functionality. Then the World Wide Web came and new, reliable and safe (although many don’t believe so) applications saw the light of day. Tapping into the corporate environment became so much easier. Also, using a computer other than one’s own became possible (e.g. internet café, a friend’s house, borrowed during vacation etc.)

Now, it’s the 2010’s where tablets and smart phones are gaining ground but also users are becoming more demanding as far as their office independence (or space constraints, if you wish) is concerned. They now need or demand mobile applications that (like web applications before that) offer them more functionality with no compromises in security. Also, more and more people are attached to or dependant on their personal smart devices (since they are no longer used just for telephoning but also for storing and processing of data, such as calendar entries, to-do lists etc. to say the least). And these people wish to bring their devices to the workplace and carry them around, freely. So the “Bring-your-own-device” (or BYOD) issue is coming to the foreground of the CIO headaches. Different devices, many times in large numbers which is difficult to predict or quantify are coming inside the corporate environment, so CIOs must solve the security problems (to say the least) that are created by the diversity of these devices. Many times there is just no option of saying “no” to BYOD. Imagine the example of a hospital where customers/patients are coming in and are likely to stay in for hours or days. They just can’t be denied the use of their personal devices!

We don’t have to duplicate here statistics that can be found easily of the net about the mobile devices penetration and use. Just some facts:

The number of smart device users is increasing in high rate. In fact, the rate is faster than the PC users of the 80’s or the 90’s.
Soon, the smart mobile devices will be more than the desktop or laptop PCs on the planet.
Mobile users in China have doubled last year, compared to the Japanese.
Building mobile applications is very easy and there already are several frameworks that assist the development process and making it easier and faster; therefore cheaper.
There is a large number of mobile apps that is offered for free (therefore it is easy for these vendors to build fast a “customer base”) and can be upgraded later for a small price (when the user will be convinced that the functionality is good and is there or wants some more). This didn’t happen with traditional web applications (although it is starting to happen with some SaaS products, nowadays).

On the above, add the projection that around 2025 we shall see a new kind of device. This is derived by the recent history of technological evolution. We don’t know yet exactly how they will be but we do know that they’re going to be mobile.

The above are showing us that mobile computing (and the relevant business/commercial applications, which is the main focus of this post) is the future. There will be a large number of players. Many of them will come from the emerging markets of Asia (with the low worker cost). In general, mobile computing will be the nursery for many new start-ups. In my opinion, we shall see a new “bubble”, the Mobile Bubble. There will be so many players that will be asking so much money (in investments) to build new ideas. Some of them will be interesting and some not. Some will float in the “ocean of entrepreneurship” and some not.

Like to dot-com bubble of the 90’s, I foresee a similar “curve” in the evolution of mobile applications. I quote a phrase which I recently came across: “For every good dot-com idea there were a thousand bad ones” and I add: Some very good ideas never made it to produce actual profit because of problems not pertinent to their technical completeness or quality.

It seems that the “curse” of mobile development is exactly the inherent advantages:

It takes evolutionary and original thinking that usually young entrepreneurs have, who often do not have the qualifications or abilities of entrepreneurship, itself, so that they can build a viable business model.
It’s a world trend, so all those technology people seeking to do something new inevitably turn their sights to this space. This results in a large number of start-ups which in many cases do not have clear business goals (or plans!), have limited resources etc. (Large players are still in development or marketing phase. Some of them haven’t yet come down in this arena as they are waiting to see where the “ship” is going to turn to).
Modern tools make development easy but hasty decisions often result to poor user interface or user experience, in general. The average mobile or smart phone user is hasty and demanding enough, so a relatively good application which offers poor user experience is doomed to failure.

I believe that mobile computing has still a lot of ground to cover. However, definitely the future of computing is mobile (!) as devices are becoming smaller, smarter, faster, more autonomous and – let’s face it – a personal gadget that everybody wants to carry all the time, as they can combine business and personal activities with the best way. Finally, I believe that we are bound to see a “mobile bubble” in the current decade, which is going to clear the scene and, as always, prepare the world for the next technological leap. Let’s hope that we shall be here around 2020 to re discuss these issues once more!

What does “Quality” mean for SaaS products?

2013-07-09T09:48:00.000+03:00

As anything sold, quality is the first and most important factor for its success on the market (price is the second most important thing, but we will not deal with it, in this post). During my engagement with the Software as a Service business I have found out that Quality is an issue that needs to be redefined in that context. I started thinking about this, driven by the fact that “traditional” software “virtues” are not enough to build a sustainable SaaS income. By the term “traditional” I mean all the usual quality elements or performance indicators that the buyer expects from any kind of software (SaaS or not-SaaS):

To be error-free
To be fast and reliable
To be user-friendly
To be adequately supported by its vendor
To provide insight to the data that it keeps (and not just to… keep them)

My point in this post is that SaaS is a space where additional “quality elements” must be in place. I will enumerate what I have come across (and what my customers are usually challenge me on) and explain why they are considered so much more important than traditional in-premise offerings.

Extensive parameterization: A SaaS product must offer extensive parameterization options since it is by definition a piece of software that the end-customer cannot be endlessly customizing and at the same time not respecting physical or logical constraints that its creator has set. Consider one of my favorite silly examples: In a customized in-premise software, if accounting dept wishes, it can revert the debits and credits on the General Ledger module so that the debits are on the right and the credits on the left hand side (!). Imagine this requirement being served by a generic SaaS Accounting software. Either the software vendor will say “not possible, sorry” or they will create a new customer setting like this: “debits on the right: [YES]/[NO]”. The point is that in order to serve diverse customer requirements from a unique codebase (and database) the logical architecture of the system must be extensively based on parameters and user-defined settings.

User support: By definition, any SaaS business shows meaningful profit margin for the supplier only if the number of customers is high. A large number of customers increases the workload of the Support department (call center, web support, telephone hot-line etc.). The vendor needs to build mechanisms that are capable of supporting multiple users, simultaneously. This is not necessarily the case with traditional in-premise software where an on-site technician visit is probably the best (or only?) way to identify and resolve the issue. In such cases, there is a mechanism to pipeline, schedule and execute the visit. And no one expect the visit to take place instantly!

Frequency of new releases: All software vendors offer frequent upgrades and new releases for their software. In-premise software suppliers do so only if the customer has bought a Maintenance Contract, but in the SaaS business new releases are not something that could be charged for an extra fee; it is simply expected to be included in the monthly (or whatever) recurring fee. To put in different words, there is no SaaS product without a release upgrade “package” attached to it. But that’s not the main point here. The main point is that in order to be constantly on the edge, to be ahead of the competition (remember: SaaS is the tool that enables users to easily switch from one product to another, since they never “bought” anything) and to follow frequent technology curves and trends (new HTML, JAVAScript, new web browser versions, mobile environments etc.) a SaaS “factory” must constantly produce new and better releases of the software. The urgency of new releases in in-premise software is not that big, since what “used to work a few years ago” will still work unless a major PC switch is done (not a frequent case!)

Performance issues: The workload of an in-premise software & database is generally stable with slow rate of increase. Performance bottlenecks or degradation manifest themselves slowly, gradually and always give enough time to IT dept. to react. This is not the case in SaaS where the hunt for new customers (=users) in that existing infrastructure in endless. Sure, modern architectures provide all the necessary tools for scalability, high availability and fast upgrades. But in any case this means that the SaaS vendors must have the mechanism to be on top of these issues; and they are rated by their customers on this area, too.

Security: Much has been said about the security of SaaS. We shall not go into details here, but just remind the usual concern of the customers: “my data is in the cloud and therefore out of my physical reach and protection”. SaaS vendors must demonstrate impeccable positive records in terms of security. As simple as that.

Customer engagement: Because SaaS does not require any capital investment, it is a perfect tool for customers to test and adopt, if they finally get convinced that it suits their purpose. On the opposite case, they are free to abandon the service and search elsewhere. This creates a high velocity of customer transfer in and out of the service, or “churn”. In order to minimize the rate of customer movement out of your service you must be in constant contact with them. Listening to criticism, to their problems, trying to find work-arounds for problems that they see as system inefficiencies, keeping them up to speed with new releases and versions (that must come very frequently, as stated before), etc. Therefore, there is a quantity of customer engagement work that did not exist with traditional in-premise software sales. Back in the day – and for large accounts only – it was enough for the account manager to visit the customer every once in a while, discuss issues and find solutions to new problems. In SaaS it is not enough. Most SaaS vendors are employing social media and other techniques to keep a high degree of customer engagement.

A successful SaaS business implies the existence of additional (new to the market) product virtues. Ultimately, these will separate the “men from the boys” of the SaaS space, because as competition rises, buyers become more aware of these additional virtues and start demanding them instead of just seeking them. The pressure in SaaS suppliers is building up and each vendor will select some (or all?) fields to build expertise and trust.