What happens after creating a service plan: a guide to next steps to help you go from the perfect service to its technical description
Let’s pretend that we have a traditional commercial company, and we are in the business of selling locks, mainly to construction companies and to a lesser degree, private customers.
To help us better understand the touchpoints between us and our clients, we have created a service plan. Due to changes in the economic environment, we are forced to critically review our business and we have sketched a new service plan, which shows how we would like to do business in the future.
The service plan describes the client’s activities and touchpoints within the scope of the service. Additionally, it also covers any supporting behind the scenes processes connected to our clients.
So now, we have a service plan that describes the AS-IS situation and an initial vision for the future, and the question we are now left with it “how to move on from here?”. Next, we will look at some activities that can be done to move forward from this point.
Business analysis
There are different methods for doing a business analysis, but we will not be focusing on those in this article – instead, we will observe the following activities in the context of general thought patterns.
Business management guru E. M. Goldratt developed the theory of constraints, which I will follow in the text below as well. I would also like to draw your attention to a couple of the most important postulates of the theory of constraints.
- focus on the business goal – every change should follow the goals of the organisation as a whole. For the private sector, the main question is whether the change can help increase profits. If we aggregate heavily, then we are left with two sub-topics: increasing profits or decreasing costs. For the public sector, the goal is connected to fulfilling the goal set for the organisation. If your goal is to provide a public amenity, then you can focus on increasing volume or improving the quality.
- don’t focus on local optimums – a service plan is an all-encompassing tool. It covers the client’s touchpoints, behind the scenes processes etc. But at the same time, it needs to be looked at in the context of the organisation as a whole. If you wanted to realise an extremely optimised service plan, then you would need to put all the resources and processes that the service needs into this service plan. For example, when Bolt (Taxify) was just starting out and their only service was taxi hiring, then they could direct all of their activities into providing this service and to do it was well as possible. Now, Bolt’s business has expanded and also includes a food delivery service, electric scooter rental, and short-term car rental, which means that they must make compromises for any one of these services.
Optimising your organisation around one service means creating a local optimum, which oftentimes also creates inefficiency in other services. That is why it is important to optimise based on the needs of the whole.
By continuing to work with your service plan, you can evaluate how much the changes benefit your business. During the analysis process, we can determine whether the desired gains are appearing and to what extent.
The service plan also needs to be analysed to determine if the achievable business benefits are enough – for example, if the new service causes a 1-2% increase in earnings, then is it enough?
If it is determined to be insufficient after evaluation, then you can consider alternative activities for increasing your income. Once you have looked at the way the service plan affects your business, you may also decide to only realise the plan partially to achieve enough of an effect to create an increase in earnings while not creating too much inefficiency elsewhere.
Basically, a business analysis should help you understand if and to what extent you should realise your service plan. Ideally, you will have done an analysis on your competitors and the market before creating the service plan as that ensures that the service plan has not been created for a field with no future prospects.
Figure 1: stages of business intelligence
In any case, a business analysis will add a financial dimension to your service plan. The next steps will focus on dividing the service plan touchpoints into one or more information systems.
Each touchpoint in the service plan may use a different information system or they may all use one substantial system. We will continue talking about a pre-analysis for information systems from here, but it can be applied to one or more systems.
Process analysis and pre-analysis
A process analysis involves organising the activities on a service plan into logical diagrams that show all the different events, activities, decision points and roles involved.
Process analyses are visualised as diagrams and in Estonia, the BPMN standard is used most often to do so. The diagrams may vary in terms of their level of detail but in general, the diagrams meant for the business side are more aggregated and simpler while those meant for IT are more detailed (and much more complicated to read and understand for business).
A process analysis helps to validate and flesh out the logic in the service plan and to identify any exceptions. For example, we just recently had an analysis project, where one application needed two applicants to pass, which created two edge cases:
- what happens if the other applicant rejects the application;
- what happens if the other applicant does not confirm the application.
By using this simple example, we can make amendments to the service plan as well as address these situations during the process analysis process.
Any additional constraints cause by other fields are also reviewed during the process analysis. When creating the service plan, it is always better to let your imagination fly free and try to aim for innovation.
Unfortunately, there are always conditions that we have control over and those we do not. We can adapt the conditions that we do have control over for the service plan and achieve the desired result.
And we must account for the conditions we have no control over and adapt ourselves to those. A typical example of this would be the Estonian Financial Supervision and Resolution Authority’s guidelines for credit companies.
If you wish to enter the market with a completely new financial service, then we can design it to be quite creative. Unfortunately, to get a creditor’s licence, the service and its supporting systems must follow the conditions set out by the Estonian Financial Supervision and Resolution Authority.
Just recently, we analysed a public sector project where the service plan included a lot of features that would have had a very positive effect on the clients.
But during the process analysis, the terms of processing sensitive personal data were determined and since this type of data is not allowed to be used in the way the project would have required, then those features were left unrealised.
Further, a process analyses helps to identify bottlenecks – any resources that affect the overall speed of the process and that, when overburdened, cause delay for all parts of the service.
Figure 2: visual description of process analysis
Identifying bottlenecks is one of the central aspects of the theory of constraints mentioned above. If a resource is identified as a bottleneck during the process analysis, then that part of the service must be optimised to relieve the pressure on the bottleneck.
This may mean having to abandon some activities, transferring them to another resource, offering tools or aids to help increase the efficiency of the bottleneck’s activity.
This is also the point where I would like to remind you that we should aim to avoid local optimums and if we get rid of the bottleneck completely, then it will only reappear somewhere else. Additionally, the bottleneck may not be within the service’s main process but instead, in one of the supporting processes.
A process analysis forms the basis for describing the features of the future information system. This is often also called a pre-analysis, which includes a process analysis.
The purpose of the pre-analysis is to describe the information system from a technical standpoint – it includes all functional requirements, non-functional requirements, the business information model (including the main entities managed within the system), status diagrams in some case etc.
The activities and decision points will form the main functionalities. The inputs and outputs of the process will form the main entities of the future data model (and they will be assigned attributes during the detail analysis after which they will become database tables) and their relationships.
Figure 3: Visual description of preliminary analysis
Additionally, you can also decide to leave some of the activities out of the information system and do them manually instead, which helps to cut some costs during the development phase of the system.
There are multiple different methods for describing functionalities in the pre-analysis. The pre-analysis must convey the vision of the information system. But the pre-analysis will remain at the vision level and any technical specifications functionalities will be described during the detail analysis.
Both the process analysis and pre-analysis are important steps towards specifying the technical description of the service, during which new aspects that must be accounted for are uncovered.
It is strongly recommended that you supplement the pre-analysis with a general wireframe prototype and vice versa. A lot of article have been published about prototyping in our blog – I would recommend reading the two-part article series “How do prototypes complement analyses?”
Onwards to development
„The business vision for moving forward originates from the service plan. During the business analysis, we will determine that it is the direction we wish to go. The process analysis helps us determine what our business activities will start to look like. The pre-analysis provides clear requirements for what the future information system must do, and the prototype gives us a general wireframe-level overview of its design.“
How do I know how much all of this will cost me? Before answering that question, we must talk about indeterminacy. Namely, if your service is innovative and uses new technologies, then the indeterminacy of that situation is a lot higher.
In that case, the functionalities described during the pre-analysis are more aggregate and provide a more general framework to work with. Lower indeterminacy is present in situations where the processes and technologies are already familiar to us.
In any case, it is important to ensure that the pre-analysis and the initial prototype can be used to provide the client with an indicative overview of the costs.
For a precise overview of the costs, you need a detail analysis where the requirements and functionalities of the project are specified from a technical point of view.
For example, the main business entities are described on an attribute level, various intermediary tables that allow us to manage relationships are specified between the entities. For use cases, alternative flows are described.
For interfaces, the format of the data being exchanged and the requirements for addressing the interface are described. Roles and their privileges are also elaborated on. And this list only includes a few examples. The fact is that a detail analysis is necessary for development.
The detail analysis may be a separate project, or it can be done as part of the development phase. Usually, for development projects, a detail analysis is done before development work starts on a specific part of the system. Most often, this is done for incremental development projects.
Detail analyses that are done before development starts can provide the client with much more precise cost evaluations. On the other hand, you must take into account that doing a detail analysis takes time and often, new situations and conditions appear during the development phase, which means that we must go back to the detail analysis and start updating it.
The only kinds of projects where you can get away with not doing a detail analysis are extremely traditional solutions (e.g. a simple website or online store).
Figure 4: Visual description of the detailed analysis
In conclusion, a service plan, process analysis, pre-analysis and wireframe prototype are enough to provide an indicative overview of the costs for the development.
But in that case, you must also consider that before you start developing the new solution, you will definitely also need a detail analysis. If the detail analysis is done, then your overview of costs will be more precise, but you will still need to adjust and make corrections to the detail analysis whenever any new information arises.
