Cloud application and remote work

Cloud SaaS vendor often put forward that their application can be implemented remotely contrary to on-premise applications. Is that true? And what does it mean to implement a SaaS remotely?

Can we implement remotely on-premise applications?

Nowadays, many on-premise applications are managed remotely:

  • Infrastructure monitoring and management is outsourced to a team sometimes located thousands of kilometer away.
  • Application management is handled by multiple teams from different locations within the company.
  • With new VPN features, infrastructure and application management can even be carried out outside the company.
  • Companies have implemented all technical tools to work remotely: chat, audio and video conference, shared file management, shared bug tracking.

In truth, the only action that cannot be done remotely is the physical installation of the application, the physical management of the architecture and the physical side of the backups, notably putting tapes in tape reader.

What is different for a Cloud application?

First, in a cloud application, the customer and the implementation team doesn’t have to care about the physical side of the server management. It does still exist: try to ask for a restore of a cloud instance of you application and you will face the traditional delays related to physical actions. But as long as you don’t have to go this low, everything can be done remotely.

On top of this, Cloud providers have implemented a business model where implementation are entirely organized and carried out remotely. But the work could perfectly well be realized on site. And when the implementation requires a link between the Cloud Application and other tools in the company, the vendor will switch to a new model and an on-site team.

What is interesting in working with a remote team?

First, it allows the vendor to create a pool of experienced consultants that share all the time tips and tricks from their implementation. This allows them to become more experienced, compared to traditional team who work isolated with different customers. So, the customer will benefit from better teams.

Secondly, the close proximity between the consultants will enable them to have a more industrial approach for the implementation. The project will be more efficient in this way and the outcome more predictable for the customer.

Last, since the consultant is not working at the customer site, he can work for different customers when his workload is not 100%. So the customers do not pay for the time where the consultant is under-used on site.

In short, working remotely in a pool of consultants will enable the consultants to be more experienced, more efficient and less expensive. And this will benefit immensely the customer.

What are the risks with remote team (and how to mitigate them)?

The main risk lies in the distance.

When everything is fine, everyone sees the benefits. But if the implementation project encounters issues, either functional or technical, the team can become anxious. And the distance will not help lessen the anxiety. On the contrary, emails and phones are increasing it more often than not.

The second risk is the complexity management. When on-site, over a coffee machine, going back and forth to a meeting room, people “small” talk. And those talks are useful to share little details that add together in terms of complexity.  Remotely, the implementations will miss those details.

A recommendation and what the Cloud has brought us

For small projects, remote implementations are perfect and cost effective. Go for it.

For medium and large projects, remote work is efficient but on-site workshops will allow people to share and connect together. This will strengthen their remote work and make them even more efficient.

Remote work is here to last. Let’s make the most of it.

2017, a practical year in the Cloud

Everybody talks about the Cloud. But the actual implications of this word are not always very clear. In 2017, Amedrys worked on concrete Digital Transformation.


We have led several implementation project for Cloud Applications. Some aimed at transfering on-premise applications into the Cloud, other at implementing new solutions. It was a good opportunity to switch from traditional projects to newer ones.

A few of our articles about this

Public cloud : they didn’t tell me !!!!

Cloud implementation in weeks or months instead of years: a boast?

4 points dont on ne parle pas sur le Cloud (french)

This year, we focused on SAP Concur and SAP SuccessFactors and notably the Employee Central Module.

Training and Cloud certifications

We have also led, in partnership with Valnaos the training Professional Cloud Service Manager. This training, created by the Cloud Credential Council, provides a complete overview of services in the Cloud, from the definition of the Cloud Strategy to the daily monitoring of activities and to the economic model.

Partnership with Valnaos

Our interview on PCSM training (French)

2017 enabled us to further our Cloud certification program with SAP Success Factors Employee Central for Fabrice Rigaux.This allowed us to grow our knowledge in an operational manner. The target is not for us to directly configure Success Factors but to lead implementation with real proven knowledge.


2017 has given us the opportunity to publish our second book, this time on the Cloud: Purchase Cloud Applications.

The cloud is a real break in the SaaS management. This led us to ask ten key questions to be asked with SaaS solutions. This book has met its first successes and we will consolidate it next year.

And what about 2018 ?

We will continue our path in the Cloud. New articles, new projects, new PCSM trainings.

Beyond, we may build and deliver a Cloud Overview  in One Day as an introduction to SaaS application implementation.

Public cloud : they didn’t tell me !!!!

Cloud strategy gives us an excellent article on Public Clouds.

What are Public Clouds ? they are services provided by a vendor in the Cloud to all customers in the same way (or with the same standard options) . Opposite to it, you find Private Clouds where the customers defines exactly what he wants.

In short for busy people, what should we remenber from the article ?

  • Public Cloud have often been advertised as less expensive with low storage costs.
    • It may even be true …
    • BUT everything is the small print of the contract. And there are often hidden costs (transfer, additional services, …) beyond the initial announced costs. Sometimes, the final cost is far less interesting than appeared initially.
    • Don’t forget. The vendors are here to make money. And they need to if you want them to provide your services longer.
    • Our recommandation : read all small lines and simulate expected total costs. Test on a small volume of data or transactions. Then track the Cloud Deployment to verify that no new costs appear.
  • Recently, there was a bad streak of service shortages in the big Public Cloud everywhere in the world.
    • Said otherwise. Big Cloud Public don’t fall often but when they do, they have massive shortages.
    • When it happens, customers have no actions possible to restart services or even to the priority order of the restart. The customer waits for services to be available again and for a potential reimbursement, depending on what was written in the contract.
    • Don’t forget the small print
      • Contractual availability is often different from actual or advertised.
      • Performance : a service can be accessible but so slow you cannot use it. Contractual availability measure access not speed.
    • Our recommandation : set up a fall back solution in advance. What do you do if you lose the service for 5 hours, 1 day, 1 week ?

Two examples out of IT to illustrate what we say

  1. Low Cost Air Travel : you read now all that is included in your fare. Because what is not will be expensive ! You were used to the small snacks offered in classic flights. Too bad. Does it forbid you from going Low Cost ? No but open eyed (and with a sandwhich in your bag)
  2. Public transport : one urban outfit only counted late train when they were below 30 min late. Above, they disappeared from the statistics. They had a very good availability. Did it forbid people to take their train. No but open eyed (and a book to read while waiting)!

As for all external services, the relationship must be managed ! Get a service manager to follow you Public Cloud! Digital transformation is great but needs a transition period that needs monitoring.


Cloud implementation in weeks or months instead of years: a boast?

Cloud vendors often write and say very loudly and proudly that their solutions can be implemented much faster than on-premise applications. Is it true and under which conditions?

The conditions

There are four critical conditions:

  • No specifics (or few)
  • No localization (or few already known)
  • No interface to other applications
  • No data migration beyond user definition

No specifics (or few)

The speed of cloud implementation is based on standard functions. It is part of the game. So, if you want to go fast, don’t develop or configure specifics.

Often, SaaS vendors provide you with the capacity to configure specific business rules. But to do this, you need to define them, implement them (or have the vendor build a solution), and test them. And it takes time, or at least more time than the baseline provided by the vendor. If you want to go fast, manage specifics outside the solution (at least in the beginning).

No localization (or few already known)

Many Cloud solutions will require adaptations to fit local legislations or industry specific rules. In many solutions, the provider has been some localization but will require you to confirm that it is valid in your situation. From the vendor’s perspective, there are so many rules applicable to a customer that he doesn’t want to be legally responsible of your specifics. Unless he is extremely specialized.

Again, the SaaS vendor will provide you with the capacity to configure local rules. He will maybe provide a template with rules extracted from previous customers. But definition and testing will be your responsibility. And again, it will increase the implementation time. You can naturally choose to manage the local elements outside the system.

No interface

Interfacing is similar to building specific rules but worse since it requires touching another application, talking with another development team and synchronizing work. Again, it takes time. And if you need to connect two Cloud applications, this will get worse.

Some Cloud vendors will suggest to go live and replicate data manually, to provide fast the solution to your users (and go to live billing), and to interface later on. This will keep the implementation quick but will increase the workload to keep the systems aligned. What is more adapted to your situation?

No data migration

Data migration adds another complexity with history and how the old system managed the data. It requires a deep understanding on how the new application works and a lot of reference data. And acquiring this understanding will again take time when SaaS provider want to change their model whenever they need to. Many Cloud vendors will suggest you leave your old data in a long term storage “anyway, no one uses them” and only move the most recent picture of your data.


The sales pitch from Cloud vendor is real. Yes you can implement a SaaS solution fast but to do that you have to adhere to strict limits. Yet, this is your decision and yours alone. You can also take more time when you need to. Now you know what to expect and do as you need!

You want to know more about purchasing cloud applications. Read our book.