<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">
Event_bg

The Leonardo Blog

All Posts

Shifting business operations to an ‘as-a-service’ delivery model

16_delivery_intergration.jpg

As SaaS solutions become commonplace in several industries, the market has felt the effects. IDC research shows that SaaS technologies are projected to constitute a quarter of all new enterprise software purchases by 2016, while PWC estimates that SaaS delivery will make up approximately 14.2 percent of all software spending. Overall, the entire SaaS market is projected to expand at a compound annual growth rate of 21.3 percent over the next two years.”

As a consultant working within a number of large and medium sized organisations over the past several years, I’m used to seeing common problems being solved over and over again, everywhere I go. Some big and some small, some more necessary than others and some with varying degrees of ‘fit for purpose’ tweaks. After all, every business is different and every implementation needs to fit the business context around what it supports.

Shift toward ‘as-a-service’

However, there is a shift taking place and more and more businesses are starting to see the benefits of moving towards “as a service” type arrangements. The transformation isn’t necessarily a new one; the introduction of web based email and corporate social networks have become a staple of the modern organisation, as well as support and maintenance team products such as Sharepoint, Dropbox and Skype. 

All of these functions within the business which have begun the transformation to Software as a Service offerings have one thing in common which confuses the bigger picture. They generally still fall into the IT or technology bucket of the organisation. They perform well serving their single purpose but very often they support a technical role within the business - after all they are still technical tools.

Business Function/Operations ‘as-a-service’

The bigger piece of the pie which is yet to be realised by large business is that the ‘as a service’ offering shouldn’t be limited to internal tech centric applications. The transformation should be steering towards the business function and operations ‘as a service’. That is to say, the foundation on how that business actually conducts itself and generates revenue. 

It very often still dominates business projects, and projects take time. Time costs money, and money is often the thing which is trying to be made or saved when projects are kicked off. 

Occasionally, we still the response from project teams and management which is to throw people at the problem. But more people equals more churn and faster turnaround time – and we all know how that one ends. The project blows out and you’re likely no closer to achieving the goal set out to in the first place. 

I’m talking specifically about the technical delivery of projects, and even more specifically about the system integration component of technical project delivery – the thing which enables the business to achieve its outcomes, service its customers and generate revenue.

When I talk about the difficulty of successfully implementing projects which have a large integration requirement, one of the main issues that arises consistently (n.b. this could be due to a potential disconnect between responsibility and understanding) is that it is underestimated just how specialised systems integration is.

Considering the people required to deliver the role on the project, reflect on the complex role for an integration specialist. It requires someone with an array of technical know-how across varying applications, with enough knowledge to understand how different systems work and what they are capable of handling. Projects additionally require that same someone to demonstrate an understanding of business functions, use cases and context in order to be able to implement appropriate solutions to business problems. In order to do that effectively, they also need to be a product specialist, and have a deep understanding of the very tool, or tools, which will be used as the integration platform of choice.

It’s a tough ask, and in the grand scheme of things it’s not surprising that these people are both expensive and difficult to find.

A pain point for many project managers is ‘Where do you start when you need to find someone with the right skills for the job, with experience in the appropriate industry, within the allowed budget and available when you need?’

Benefits can be truly realised for many businesses to de-risk and implement the move towards ‘delivery as a service’. Here are benefit we see from taking such as shift:

  1. Reduce IT expenditure / cost overheads and barriers associated with everything that comes with integration projects.
  2. Speed up delivery, and clear the path for far more efficient implementation teams.
  3. Improved project alignment and operation efficiency. 

The first step in the ‘as a service’ movement has been taken by many businesses, and has reached the technical support functions. It’s now time to consider the bigger picture and broaden the possibilities of what can be achieved by paving the way for integration delivery to be provided as a service as well.

New Call-to-action

Dane Porter
Dane Porter
Dane is a professional services consultant with a strong background in information technology solutions, particularly with respect to systems integration; having worked in software development and design roles across various major projects, he has an understanding of the industry from both a technical and a business standpoint

Related Posts

How To Replace Random Acts of Management With a Metamodel of Improvement

The simple existence of a problem is not enough reason to invest in fixing it, perhaps not now, perhaps not ever. Organizations need a systemic approach to define what good looks like, assess current performance, and make evidence-based decisions about which performance gaps to close. The Tregear Circles replace random acts of management with a metamodel for continuous process improvement. I have recently encountered several examples of the idea that higher process performance target scores are obviously better than lower ones, just because they are … well … higher; that setting a target of, say, 95% is, without doubt, better than a target of 88%, and in striving for improvement we should go 'as high as possible'.

Why Open Source Thrives on Cooperative Competition

Although I’ve spent the majority of my career on the consulting side of the fence I’ve also spent ten years on the client side, in senior IT roles, where I purchased a lot of software.  It was in 2006 that software sales people started offering alternatives to the traditional model of licence plus annual maintenance for proprietary software. These sales people were offering SaaS solutions and subscription-based open source software, neither of which I seriously contemplated buying.  Given that SaaS and open source software are now an everyday part of the IT landscape - why was I entirely unwilling to consider them a dozen or so years ago? The answer is simple. In neither case did they offer the benefits they do today, and, worse, the people selling them struggled to articulate what the real benefits of their offerings actually were. For the purposes of this post I’ll leave the SaaS model aside to instead focus on open source software. 

3 Ways to Measure the Usefulness of BPM

  In the fair dinkum department, the most important question about BPM must be "is it worth the effort?" It works in theory, but does it work in practice? What is the return on process? How should we measure, and report, the outcomes of process-based management?   The Wrong Answer Let's deal with the wrong answer first. It's not about the artifacts. No organization has a business problem called "we don't have enough process models." It is not a business improvement outcome to say we've trained 50 people on Six Sigma analysis, or appointed some process owners, or modelled a process architecture, or assigned process KPIs — these are all necessary, but none is sufficient. To the executive not yet fully engaged with the promise of process-based management, all this activity might sound more like a problem than a solution, more like a waste of resources than a successful outcome. And if that is all that is happening, she would be correct. We need good models, architecture, methods, and training — a metamodel of management — they are a means to an end, but not an end in themselves. Just having management tools is not the point; we must use them to deliver real organizational performance improvement. If our process management and improvement activities are not delivering measurable, objective, proven organizational performance improvements — improvements better than we might have otherwise achieved — then our process activity is, by our own definitions, waste.