Business

The phrases cloud, self-hosted, and on-premises are used a lot these days and are usually well understood, by IT professionals and by the “non-IT” person. For the sake of being clear, the generally accepted meanings of each term will be covered first in this blog. Besides clarifying this for anyone reading this that is not familiar with the terms, establishing a common reference is needed to further discuss key considerations and the pro’s and con’s of each when deploying a solution.

======================================

What are cloud solutions?

A solution on a cloud server means that the solution is deployed on a server, usually a virtual server, which may be owned or at least managed by a third-party service provider. Often the solution itself is owned and maintained by the same or a different third-party service provider. In other words, the third-party service provider(s) would manage the server environment and maintenance thereof, as well as the deployment and maintenance of the solution on behalf of the client. The client using the solution would access it via internet connectivity.

What are self-hosted solutions?

The term self-hosting needs to be clarified in terms of this article, since there are differing opinions on what self-hosting is. Some have the opinion that self-hosting refers to owning physical servers at a location owned by an organisation, on which the solution is deployed, and which is accessed via a local, internal network only. However, others hold the opinion that self-hosting simply means “self-hosting means running services on servers you control, [whether] in your home, in your office, or in a data center, [and that] you manage the service yourself instead of handing it over to a third-party provider.” [emphasis added; Digital Sovereignty (Hetzner)]. For the purposes of this article, self-hosted will refer to using external servers that are under the direct control of whoever is using the solution. It goes without saying that accessing external self-hosted servers will require internet connectivity.

What are on-premises solutions?

On-premises solutions are where the solution is deployed, hosted, and maintained on a server within an organisation’s infrastructure. Typically, this is a physical server that is procured, controlled, administered, and maintained by that organisation’s in-house IT department or possibly an IT service provider. The solution can either be an external sourced or procured solution, or an in-house developed solution. Access to the on-premises solution is usually limited to the organisation’s internal network.

======================================

Key Considerations

When considering where to deploy solutions or where solutions should be hosted, there are several key considerations which could influence the decision:

1. Cost
2. Control & customisation
3. Compliance
4. Security
5. Maintenance & Support
6. Connectivity & accessibility
7. Performance, reliability & scalability

The key considerations have been combined into and limited to the above points, but the list of considerations could be longer for specific applications, industries, or geographies.

1. Cost

There are two cost components to consider the initial investment and the ongoing cost of implementing a solution.

Using a cloud solution does not require an initial investment, however, there will be ongoing costs for the cloud-based solution, which would include subscription fees and/or hosting costs. The ongoing costs often increase as more users are registered on the solution and as server processing time, storage space, or network traffic increase.

Self-hosted solutions may require an initial investment, if there are upfront licencing fees for the solution itself or the frameworks or supporting software that the solution requires. For a self-hosted solution, there would be server hosting fees and possibly solution subscription fees, depending on whether the solution is proprietary or free and open-source software (FOSS). Like cloud solutions, the ongoing costs could increase as more users are registered on the solution and as server processing time, storage space, or network traffic increase.

On-premises solutions would require the greatest initial investment for the physical infrastructure, for both hardware and software upon which the solution is deployed. Besides the direct ongoing costs, such as software subscription and/or upgrade fees, there would also be the indirect costs, such power for servers, air conditioning and general facilities, as well as in-house or outsourced IT personnel who manage the server and the solution.

2. Control & customisation

The degree of control and customisation that an organisation requires over the solution, the data residing in the solution, and the infrastructure or network upon which the solution is used, will influence which route an organisation will take in terms of having the solution in the cloud, or on a self-hosted or on-premises server.

Generally, the more control that is required and the more customisation that is needed, of the server and/or the solution, the more likely an organisation will use an on-premises approach rather than a cloud approach. The on-premises approach, and to a lesser degree the self-hosted approach, are better suited to more control. Cloud solutions allow for the lowest control and customisation of the three approaches.

3. Compliance

In many industries and countries, there are legislative and regulatory requirements that organisation must comply with, which will influence which approach can be used. For example, data privacy laws in several countries require that data may not reside outside the borders within which an organisation is located. Many cloud solutions are hosted on servers in data centres that are in other countries, which means that compliance to local laws may prohibit using those servers. To satisfy compliance requirements, solutions can be self-hosted on an in-country server or on an on-premises server.

4. Security

Data security plays an important role in selecting which approach is chosen for a solution. It isn’t that cloud-based, self-hosted or on-premises solutions provide any more security than the other, but it is about what level of security can or must be achieved by the organisation. Typically, larger organisations have significant IT capability such that adequate security can implemented and maintained in-house. So, on-premises, or even self-hosted, solutions are a viable option.

However, on the other hand, smaller organisations typically have less internal capability to achieve the level of security they want or are required to have. So, they are more likely to rely on cloud-based solutions, which are hosted and maintained by third-party providers with adequate capability.

5. Maintenance & Support

There are multiple aspects to consider where maintenance and support are concerned. There are the maintenance and support for (a) the infrastructure hardware, (b) the server software, and (c) the solution. Each of the solution deployment options places a different responsibility on the organisation using the solution.

Cloud-based solutions require little to no involvement from the organisation using the solution, as the server and the solution are updated and supported by the third-party service provider(s).

With self-hosted solutions, and more so with on-premises solutions, the responsibility shifts towards to the organisation. The maintenance and the support of the server can be taken on by the organisation itself or can be outsourced to a service provider. The same is true for the solution itself, where the vendor providing the solution is responsible for the solution’s maintenance and support, or the organisation itself takes on the responsibility for this.

6. Connectivity & accessibility

Connecting to cloud and self-hosted solutions requires internet connectivity, and the solutions are publicly available, at least up to the point where a login is required to go further. Cloud and self-hosted solutions are typically accessible from anywhere and lend themselves to using various types of devices to access the solution, for example desktop computers, laptops, mobile phones, or tablets. They are also suited to integrations with other cloud-based services and solutions. Lastly, for the cloud or self-hosted solutions, access is easier for external, outsourced, or remote service providers which are required to maintain or support the solution.

Connecting to on-premises solutions is usually via the internal network and therefore access is limited to devices on that internal network. Opening access to the local network so that “anywhere access” is possible for remote working employees or external/outsourced service providers, means the associated security risks must be managed.

7. Performance, reliability & scalability

Lastly, the performance, reliability and scalability of the solution must be considered when considering which approach is taken. The level of performance needed, the degree of reliability required, and the amount to which the solution must scale, will each have any impact on whether it is viable for an organisation to have the internal resources and capacity to go the on-premises route, whether the organisation relies on a third-party’s capability via the self-hosted or cloud route.

======================================

In conclusion, none of the three approaches is the single, best option for every solution and for every organisation. To determine the best approach, carefully considering the above points in light of the organisation’s context, the solution requirements, and the available organisational capability to implement and sustain the approach.

Frequently the phrase “service request” is associated with requests raised for IT related services, for example new computer hardware, software installation, or system access. However, in this article and within many organisations, the phrase is being used more broadly for requests for services from across the broader organisation, from both external and internal parties.

What is a service request?

A service request is simply a request from an employee, customer, or supplier for assistance, information, approval, equipment, or services during day-to-day business operations. The requests can be raised, received, and processed informally or formally. Informal requests are usually made by email, telephone, or word-of-mouth while formal requests are managed via a service request system.

Typically, service requests fall into the below four main categories. There are some examples listed for each.

1. Customer Service: (a) Requests for equipment installations or upgrades (b) Equipment maintenance or servicing
2. Information Technology: (a) Supply a new computer (b) Software installation (c) Network connectivity
3. Financial: (a) Purchase order request (b) Business expense claim (c) Customer account administration query
4. Human Resources: (a) Leave request (b) Training application (c) Business travel request

Other categories could include legal requests for new or revised contracts, marketing requests for marketing collateral, or health and safety related requests like safety inductions or on-the-job assessments.

Why manage service requests?

Formally defining a service request management process and using a service request management system ensures that all incoming requests are logged, prioritised and resolved correctly, consistently, and efficiently. Standardising the information required to submit a request, as well as standardising what services are available and how those services are delivered, ensures consistent service delivery quality and maintains the required turn-around time to resolve requests.

Additionally, consolidating incoming service requests across customers, employees and suppliers into one service request management system leads to improved productivity. This is achieved by directing all service requests within a category to the appropriate, specialised resource to resolve the request, regardless of the source of the request. For example, customer account administration requests, employee expense claims, or supplier purchase order requests can be sent to a finance department directly.

Another benefit of using a formal and consolidated service request management system means that the progress of service requests can be tracked centrally and that the reporting is available for the entire organisation.

How to manage service requests?

At a high level, there are at least four stages in managing service requests, namely submission, assessment, fulfilment and closure.

Submission: At this stage the originator of the request submits their request, providing the necessary and any additional information which will be used to categorise and prioritise the request.

Assessment: During the assessment stage, the validity of the incoming request is initially assessed, it is categorised and prioritised, and is subsequently assigned to the team which must address the request.

Fulfilment: The assigned team will address the request and either re-assign it if necessary for additional work by another team or move the request to the closure stage.

Closure: Finally, request is closed and the final status of the request is updated, and the requestor is informed of the outcome of the request. It is good practice to ask the requestor for feedback on how satisfied they are with the outcome of the request.

In summary, a service request management system connects customers, employees, and suppliers to the right support staff, boosting productivity, improving customer service, reducing turn-around times, and enabling automation. The unified approach of an all-encompassing service request management system delivers fuller visibility and control over every request, driving closer collaboration and a measurably better experience for both internal and external stakeholders.

As the phrase implies, Supplier Relationship Management (SRM) entails managing the lifecycle of a business’s suppliers from selecting and onboarding suppliers right through to offboarding suppliers.

Although, most businesses have suppliers, they often do not put the same level of effort into building and managing the relationships with those suppliers as they do with their customers. Sure, without customers, businesses would cease to exist. However, without suppliers, businesses would not have products or services to supply to those customers or at least they would not have the ability or capacity to provide those products or services.

Besides the obvious strategic importance of managing suppliers, there are several benefits to managing supplier relationships. Amongst others, these include:

• Securing the supply of goods and services.
• Maximising product or input material quality.
• Minimising supply costs.
• Reducing supply chain and compliance risks.

SRM encompasses the following stages:

Selection & Evaluation:

Finding and selecting the appropriate suppliers is done by clearly defining what product or service is required from a supplier, receiving the required information or proposals or quotes from potential suppliers, evaluating the potential supplier offerings against the supply requirements, and appointing the preferred supplier.

Onboarding:

Ensuring that the preferred suppliers are correctly onboarded is essential. It is at this stage that the supplier gets a deeper understanding of the business’s operations, enabling the supplier to better meet the operational requirements. It is at this point that communication channels are clearly established and when key role players from both organisations initially meet and start building working relationships.

Performance Management:

Right from the initial selection and evaluation stage, right through to the offboarding stage, there will be clearly defined supplier performance indicators, against which the supplier’s performance will be measured, and which will be used to implement any corrective actions.

Development:

Depending on the nature of the relationship with the supplier, many businesses will assist with the development of their suppliers, through business and personnel development programmes or financial assistance.

Risk Management:

Regular reviews and audits of supply operations mitigate the risks of non-compliance to regulatory requirements and to internal business standards. Any corrective actions to address non-compliance are implemented by both the business and the supplier.

Offboarding:

The final stage in the SRM lifecycle is the offboarding of a supplier. This involves either the normal relationship end-of-life between a business and the supplier, or the termination of the supplier relationship due to inferior performance or unresolved non-compliance.

Although the relationship with a supplier may vary in terms of the goods and services provided by the supplier, the strategic importance of the supplier to a business, the short or long term nature of the supplier relationship, or the business environment such as the industry, it is crucial that some level of SRM is in place to minimise costs, reduce risks, sustain quality, and enable customer service.

The benefits of automating workflows are commonly understood and accepted. Every business wants to improve the quality and consistency of their customer service. Every business wants to improve productivity. Every business wants to reduce costs. Every business wants to accelerate their product or service delivery.

Often the reasons given why workflows are not automated is that there is insufficient capacity or capability to do the automating, or that the workflows themselves are inadequately defined or understood. However, it is not often that the reason that a workflow is not automated is because it is not justified.

This leads to the question: Should every workflow be automated?

To answer that question, it is important to understand the nature or characteristics of the workflow which is being considered for automation. Workflows can be simple or complex, in terms of the steps or conditional branches in the workflow. Workflows can have a focussed or broad scope in a business, defining the flow of work in one department only or across multiple company divisions. Workflows can also be static or dynamic, referring to how the workflow changes due to organisational, technological, financial, or other factors.

Once the workflow characteristics are understood, it will be easier to determine how each workflow automation will deliver a nett return and how much effort is required to implement and maintain, where the nett return is the value or benefit gained when a workflow is automated, and the effort is the number of manhours, the technology required, financial investment needed, or operational expenses incurred to implement and maintain the automation.

Referring to the four-quadrant diagram, it goes without saying that workflows that fall into the top left (green) quadrant must be prioritised for automation immediately. The workflows that should be automated as soon as possible are those that fall into the top right (light green) quadrant. Any workflows that fall into the bottom left (light orange) quadrant should be considered for automation, but only if there are adequate resources available and there are no other more important or urgent business priorities. Workflow automation that falls into the bottom right (dark orange) quadrant is not justified, where the nett return is low and the effort is high.

Applying this methodology will ensure that the workflow automation nett returns are maximised and the effort required to implement and maintain the automations will be minimised. More importantly, it will also avoid efforts to automate workflows which is unnecessary and unjustified.

Choosing the right software for an organisation can be daunting. One of the choices is whether off-the-shelf or bespoke software will be best for an organisation.

To clarify, off-the-shelf software contains a general set of features with some particular functionality in mind (e.g. finance, projects, CRM, etc) which can be used by broad range of organisations. Bespoke software is specifically developed for a single organisation with very exact requirements and possibly with specific functionality in mind.

When faced with the off-the-shelf or bespoke choice, remember the following:
• No ‘right’ or ‘wrong’ answer
• Not a ‘binary’ choice
• Not a ‘single’ answer

No ‘right or wrong’ answer
The decision to go with off-the-shelf or bespoke software depends on several factors. Each organisation should evaluate their choice in light of these factors and ensure their requirements are met by the software finally selected.

Not a ‘binary’ choice
In reality, the choice is usually not one-or-the-other. Many off-the-self software solutions come with many customisable features, allowing an organisation to configure the software to meet their specific requirements. Also, bespoke solutions often contain some functionality which is common with off-the-shelf alternatives. In other words, there is seldom a pure off-the-shelf option which requires no customisation and there is seldom a bespoke solution which is completely unique with no common or generic functionality.

Not a ‘single’ answer
It is also quite likely that a single organisation will select off-the-shelf software for certain functions in the organisation, but will need bespoke software for other functions or business processes. For example, financial software requirement could be satisfied with off-the-shelf software, while inventory management software for very unique, specific products will require bespoke software.

When selecting a software solution for an organisation, and when choosing between off-the-shelf or bespoke software, the following factors should be considered:
• Functional requirements
• Total Cost of Ownership
• Timeline

Functional requirements
Software needs to provide a solution, solve a problem and/or provide improvements. It needs to satisfy certain requirements. It is therefore important that an organisation clearly defines what it needs a software solution to do, regardless of whether it is off-the-shelf or bespoke.
If the requirement list is very specific and unique to the organisation, then a bespoke solution is better. If the requirements are more general to the industry or organisational function, then an off-the-shelf solution is better.

Total Cost of Ownership
Off-the-shelf software is typically cheaper than bespoke software, especially to implement and over the short term. However the total cost of the software should be understood for the entire lifecycle, from acquisition through operational maintenance & support, including enhancements, and right until its end-of-life.
If an organisation has budget restraints, an off-the-shelf solution is better. If an organisation has the resources to support the software’s entire lifecycle, a bespoke solution could be considered.

Timeline
Deploying bespoke software takes longer than off-the-shelf software, but often patches/enhancements can be rolled out quicker. Also, if the bespoke software is developed in-house, it can take time to create the internal capacity and capability.
Software solutions with medium or long term objectives in mind can be bespoke solutions, whereas short term objectives are more easily met with off-the-shelf software.

So yes, choosing the right software for an organisation can be daunting. However making the appropriate choice upfront maximises the benefits and minimises the risks of owning the software, whether it is off-the-shelf or bespoke.