Is Saas a killer of change?

by bold-lichterman

While technology allows major advances, it is not self-sufficient. It’s been ten years or so that we have seen the arrival in companies of software allowing to totally reinvent operating methods, business processes, the way we work and I find that even if change has never been easy, companies are less and less ready to appropriate novelty.

We can of course question the speed of change and the speed with which these solutions are appearing in the landscape. This undeniably matters: the more changes there are and the faster they happen, the more difficult it is to cope with them.

There is of course the solutionist drift who wants every problem to correspond to a magical technology that will solve it in a snap. The truth is that a software is only worth by the way in which one conceives and implements its use, itself dependent on the context of the work. We cannot expect a solution to work in a context where the assumptions that prevailed in its design are not valid.. Which brings us back to a stupid story of change. But the existence of the Saas model for acquiring a solution does not make things easier. Even if we know that the solution will not change anything on its own, it is so tempting to say to ourselves “I sign, it is deployed in two minutes and you never know, a miracle can happen”.

And then it has precisely the other facet of this dimension of the Saas model: immediately purchased, immediately deployed. Or almost.

There was a not so distant time when we were in the opposite excess. We chose a solution and the time it was deployed and integrated we took 6 months, 1 year, or even more. Frustrating as possible, but while the IT department was tackling this heavy task, the others had plenty of time to prepare for what was going to happen on D-day. We conducted impact studies, we developed communication / training / support systems searched (sometimes too much), we got ready and we had plenty of time to prepare for the landing.

Today everything goes through technology. This is good because it opens up an almost infinite field of possibilities in terms of new products. It is also a bad thing because the shortcuts are easy and we quickly come to the following conclusion: “if something happens it should be seen on a screen”. And since the software that appears on the screen is available almost immediately, that companies have long fallen into an obsession with the short term and that the sponsors of any project whatsoever want to quickly recover the fruits of their investment or punish the culprits, from the moment a purchase decision has been made and the software can be available the next day, we want to see evidence of the change the day after.

Which leads to two things.

First of all, the teams who should lead and support the change do not have the time to prepare for it and even less to prepare those who will experience it.

Then, since funders want to see things quickly, we try to show them. Hence the insane energy expended to bring to life “on the screens” model apartments that bear no resemblance to the reality of what happens in real life, in offices.

Of course, not all projects using SaaS solutions experience these drifts. In fact, it is essentially a function of the number of people involved. If we take essentially business projects such as HR for example, the impact area is small and easy to assess. We can take care of all the people concerned (even if it is not easy) and all the more so since these projects still require a minimum of configuration, we keep a window of fire sufficient to prepare. And again… provided that we really take the trouble and that we do not botch the work on the pretext that “the software of now is simple and intuitive and if it is deployed quickly it must be used quickly” .

Conversely, we have often touched the fund in terms of collaboration. There it is potentially the entire company that is affected and there are thousands of people to support (or more) and an infinity of use cases, needs, different situations. Hence a very mixed adoption and platforms kept under artificial respiration by dint of community management (you know … so that there are things on the screen) while nothing really changed in reality

One last point which is not neutral: the advantage of Saas is the speed of updates and various improvements which are carried out over time and are delivered at regular intervals. On the other hand, this is not always clearly announced and documented by the editor, especially when it comes to a minor adjustment or a test launched on a sample of the population to see if the transplant takes and decide on ‘give up or generalize. Internal teams at the client are therefore not always informed and when they are, they often have neither the time nor the means to anticipate. In any case, it is illusory to think of being able to manage this on a large scale when the novelties fall every two weeks or every month, were they minor. Indeed the adage according to which, in his private life, the user accommodates the evolutions proposed by the editors (Google, Facebook) naturally is only rarely verified in the context of work. The slightest movement of a button or the change of its wording quickly becomes a matter of state. I will also be curious to see, now that Facebook at Work arrives on the market, how the same user will experience the same evolution of the interface or of a functionality depending on whether it is in his personal or professional context.

One advantage of Saas, however, is that it allows you to learn from experience, using the solution. A good point offset however by the fact that we only have one chance to make a good first impression. If the first impressions are mixed, the users will not come back, even though we have improved the training modules and support in the meantime.

Make no mistake: I think the speed of provision and deployment of Saas makes it a real opportunity. But because it allows new approaches, it also asks those in charge to deploy it more vigilance and places more responsibility on the shoulders (such as saying “it’s available … but we wait to be ready …” Which requires a certain courage). Deployment in SaaS is like inheriting a nice sports car: it’s powerful but it requires a certain mastery, even if it means taking the time and not pressing the accelerator immediately.

Photo credit: Fotolia, royalty-free stock images, vectors and videos