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