More detail about Fit-gap analysis #

Let’s consider in more detail the issues of analysis of convergence (Fit) and gaps (Gap) of the suitability of the AccountingSuite for the company according to its requirements. How to conduct such an analysis (by the contractor/partner) according to the received specification of functional requirements and how to interpret these results (by the customer)?

If the performers are not external specialists, but a team of employees on the company’s staff, then the approach is the same. From here on, the “performer” is the specialist responsible for automation and well aware of the AccountingSuite in question, and the “customer” is the party interested in the project, even within the same company.

In fit-gap analysis, the list of requirements from the customer is taken as a basis, it is transferred as part of the RFP (Request for proposal), divided into sections (modules) of the system: Sales, Purchases, Accounting and Tax accounting, Production, Bank, etc. This list is converted into a table, if it was not originally in the form of a table, and columns for analysis assessments are added to it.

A typical table template for performing fit-gap analysis contains the following columns:

• Requirement name – a brief description of the criterion for evaluation
• Priority – importance and order for automation: 1 – highest priority, 10 – lowest
• Mandatory – criticality of implementation at the first stage for launching into operation (the so-called must have — must be immediately)
• Support – supported out of the box
• Setup – supported by system setup (does not require programming)
• Modification – supported by customization (requires programming)
• 3rd party – support for third party solutions
• Will be in the next versions – support is announced in the next versions of the solution
• Not supported – cannot be done, technical and functional limitations
• Commentary on the requirement – explanations of the requirement, links to other documents with a detailed description
• Commentary on the fit-gap assessment – explanation of the selected mark during the analysis

The options for formatting the table for analysis are different, depending on the methodology used (they can be included as ready-made templates in the appendix to the methodology). The template can be required by the customer himself, which is logical: then everything will be reduced to a single form.

The Modification and Setting columns , considering them as modifications, but there is a difference between them. Whether you need to involve a developer or not, then such modifications in the code need to be carefully checked for compatibility when updating the system to new versions. There may also be different labor intensity of work on modification of the system or settings of options, access rights, appearance of forms, etc.

A difference between Supported and Customization , although it can be argued that if something is configured without modifications, then it is already supported. But in practice, these can be different labor costs: there is one by default or you need to configure it, describe the rules of operation, model the options.

The allocation of support through third-party solutions is also interesting – these places will require integration and additional costs for the acquisition of the solutions themselves.

In any case, the list of evaluation criteria can be shorter if the division is not critical. In special cases, this can be two columns in the table: fit (supported) and gap (not supported). Actually, that is why the fit-gap analysis . But the nuances are significant. They will then have to be described in the comment. For example, “not supported” — yes, but it can be improved. Or vice versa — “supported” — yes, but not out of the box, but after modifications or installation of third-party solutions.

Another version of this table: one column ” fit-gap “, in which a numerical assessment of convergence or gap is entered. For example, on a scale from 10 to 0, where 10 is ideal, 1 is not suitable, 0 is impossible to improve. Then the intermediate assessments show the degree and complexity of improvements.

How, in fact, to fill out this file on the performer’s side?

All experts (colleagues from the contractor company) are involved in the system:

• Do study the system and its documentation, and model accounting situations in it.
• By sending out an email to each person to evaluate their block and to get an initial overview of the requirements.
• In the form of a brainstorming session in a meeting room, where everyone gets together and discusses what is meant by each requirement point, how it relates to the capabilities of the system, and whether we can improve and customize it.

If something is unclear, these points are clarified with the customer: another iteration of additional estimates or clarifications will be required immediately by phone/messenger with the person responsible on that side. An estimate is given based on the understanding, and a comment is written on the estimate, what was meant by this, if ambiguity of interpretation is possible.

At this stage, it is difficult to understand in detail the need for revision or how exactly everything needs to be set up based on the requirement name and a few phrases in the comment. Rather, it is a quick analysis: is there such a possibility in the AccountingSuite system as stated in the specification for the software product or is this a limitation that is known (unknown) how to overcome. Here, the real expert experience of the project team and good intuition are needed so that the marks are as accurate as possible.

For the contractor/partner, such a quick analysis will show areas that will need to be worked out in more detail for a better understanding and clarification of the implementation budget estimates already during the full-fledged project, in the analysis and design phase.

The customer, collecting such fit-gap tables according to their requirements, can compare them with other 1C Enterprise solutions, this will allow determining the applicability of a particular AccountingSuite or 1C:ERP World Edition system if there is a choice between different 1C Platform ERP-system. Therefore, it is advisable to add columns for fit-gap analysis immediately on the customer’s side, so that all participants solutions work with one RFP template and then it will be possible to compare the results.

If the table is large and visual comparison is difficult, an additional column is introduced with scores for each mark, where points are entered: support “out of the box” – maximum, “not supported” – zero. Then the winner is determined by the sum of points.

It may turn out that in some sections one system is better than another, and in other sections everything is the other way around. The choice is not easy when there is no clear leader. It is necessary to look at the systems live at the next stage and take into account the factors of non-functional requirements (cost, performance, etc.).

But if the system is not suitable at all, then this will be immediately visible from the continuous “gaps” in the analysis.

In practice, fit-gap analysis is rather rare or its detailing is rather superficial, not hundreds of lines in the table, but dozens. This is due to the fact that it is difficult for the customer to independently collect detailed functional requirements at the initial stage – this is a task for specialists for project inspection. And this is an independent mini-project, the purpose of which is to obtain a document containing the requirements and immediately the result of the analysis in relation to the AccountingSuite system.