The post has been translated automatically. Original language: Russian
You can't refine the standard one.: how GAP analysis saves 1C implementation from endless improvements
On 1C implementation projects, the phrase is often heard: "In the previous system, we did things differently." After that, there is a requirement to change the document, add a new status, move the button, or develop a separate report.
But any difference from the old system does not mean that 1C lacks the necessary functionality. Sometimes there really is a functional gap in front of the team. In other cases, a typical mechanism already solves the problem, but it does it according to a different logic.
If you do not separate these situations, the project quickly turns into a chain of endless improvements.
What is GAP analysis?
GAP analysis is a comparison of business requirements with the capabilities of a typical system.
His task is to determine:
- what requirements are fully covered by the standard functionality?;
- which ones can be implemented using settings;
- which ones will require a business process change?;
- where improvement is really needed;
- which requirements are generally impractical to transfer to the new system.
The main result of such an analysis is not a list of the customer's wishes, but a well—founded register of functional gaps.
Why isn't every difference a GAP
When switching to 1C, users often compare the new system with SAP, another 1C configuration, or their own Excel spreadsheets.
For example, the customer says:
"We need the same report as in the old system."
First, you need to understand which management indicators are used in the report, what data they are generated from, and what decisions are made based on them.
If a typical 1C report contains the necessary indicators, but has a different structure or column name, this is not always a functional gap. It may be enough to configure the report option or train users.
Another example is the usual business process consists of five manual approvals, and a typical system allows you to control the operation using statuses, access rights, and the approval route. Copying an old sequence of actions just because "it used to work that way" is not always the right thing to do.
Automation should improve the process, not transfer all historically established actions to a new system.
How to identify a real functional gap
Before accepting the GAP requirement, it is necessary to answer several questions.
1. What business task does the requirement solve?
It is important to capture not only the user's wishes, but also their purpose.
The phrase "add another field" does not explain why it is necessary. It is possible that the necessary analytics are already stored in another system object or can be obtained from existing data.
2. Is there a solution in the standard functionality?
It is necessary to check not only a specific document or workplace, but also the entire related process. In 1C, one task can be solved by NSI settings, document statuses, security rules, approval mechanisms, or standard reports.
3. Is it possible to change the process itself?
Sometimes the gap is not between the requirements and the system, but between the current process and the target business model.
If an operation is performed manually just because it has not been automated historically, this does not mean that the manual procedure needs to be reproduced in the new system.
4. Is the requirement mandatory?
Legislative and critical business requirements should be separated from user preferences.
The absence of mandatory requisites for the formation of regulated reporting is a significant GAP. The unusual location of the button is more a matter of adapting the interface.
5. What is the cost of the revision and its further maintenance?
Any change in the standard configuration affects not only the implementation budget. It will need to be tested during updates, maintained and developed along with the system.
Therefore, it is necessary to evaluate the full cost of ownership of the solution, and not just the initial labor costs of the developer.
What should be in the GAP registry?
For each proposed gap, it is necessary to fix:
- Description of the business requirement;
- the current order of the operation;
- typical 1C features;
- revealed discrepancy;
- the proposed solution;
- criticality of the requirement;
- the need for improvement;
- assessment of labor costs and risks;
- the responsible party;
- the accepted decision.
Such a registry makes the discussion transparent. The customer sees why it is proposed to implement a specific requirement by configuring, changing it at the process level, or transferring it to development.
Where to put a comma
It is advisable to leave the standard functionality if it solves a business problem, provides the necessary control and allows you to get the desired result - even if the sequence of actions differs from the usual one.
Refinement is justified if the standard mechanism does not cover a mandatory legislative requirement, a critical industry process, or the necessary management analytics.
In this case, the decision should be made jointly by the business, the functional consultant, the architect and the developer. The user understands the operational need, the consultant evaluates the typical capabilities, the architect evaluates the impact on the system, and the developer evaluates the technical complexity.
What the business gets
A well-conducted GAP analysis allows you to:
- monitor the implementation budget;
- reduce the number of unreasonable improvements;
- keep the ability to safely update the system;
- identify project priorities;
- identify critical limitations in advance;
- avoid automating inefficient processes.
The main value of GAP analysis is not to find as many discrepancies as possible. His task is to find the best way to meet a business need.
Not every difference from the old system requires development. Sometimes you need to set up 1C, sometimes you need to change the process, and sometimes you need to abandon a requirement that no longer creates value.
Therefore, the correct question on the project is not "how to repeat what happened?", but "what result does the business need and how to get it with minimal complexity and risks?"
Дорабатывать нельзя оставить типовой: как GAP-анализ спасает внедрение 1С от бесконечных доработок
На проектах внедрения 1С часто звучит фраза: «В прежней системе мы делали по-другому». После этого появляется требование изменить документ, добавить новый статус, перенести кнопку или разработать отдельный отчёт.
Но любое отличие от старой системы ещё не означает, что в 1С отсутствует необходимый функционал. Иногда перед командой действительно находится функциональный разрыв. В других случаях типовой механизм уже решает задачу, но делает это по другой логике.
Если не разделять эти ситуации, проект быстро превращается в цепочку бесконечных доработок.
Что такое GAP-анализ
GAP-анализ — это сопоставление требований бизнеса с возможностями типовой системы.
Его задача — определить:
- какие требования полностью покрываются типовым функционалом;
- какие можно реализовать с помощью настроек;
- для каких потребуется изменение бизнес-процесса;
- где действительно необходима доработка;
- какие требования вообще нецелесообразно переносить в новую систему.
Главный результат такого анализа — не перечень пожеланий заказчика, а обоснованный реестр функциональных разрывов.
Почему не каждое отличие является GAP
При переходе на 1С пользователи часто сравнивают новую систему с SAP, другой конфигурацией 1С или собственными таблицами Excel.
Например, заказчик говорит:
«Нам нужен такой же отчёт, как в старой системе».
Сначала необходимо понять, какие управленческие показатели используются в отчёте, из каких данных они формируются и какие решения принимаются на их основании.
Если типовой отчёт 1С содержит необходимые показатели, но имеет другую структуру или наименование колонок, это не всегда функциональный разрыв. Возможно, достаточно выполнить настройку варианта отчёта или обучить пользователей.
Другой пример — привычный бизнес-процесс состоит из пяти ручных согласований, а типовая система позволяет контролировать операцию с помощью статусов, прав доступа и маршрута согласования. Копировать старую последовательность действий только потому, что «так работали раньше», не всегда правильно.
Автоматизация должна улучшать процесс, а не переносить в новую систему все исторически сложившиеся действия.
Как определить реальный функциональный разрыв
Перед тем как признать требование GAP, необходимо ответить на несколько вопросов.
1. Какую бизнес-задачу решает требование?
Важно зафиксировать не только пожелание пользователя, но и его цель.
Фраза «добавьте ещё одно поле» не объясняет, зачем оно необходимо. Возможно, нужная аналитика уже хранится в другом объекте системы или может быть получена из существующих данных.
2. Есть ли решение в типовом функционале?
Проверять необходимо не только конкретный документ или рабочее место, но и весь связанный процесс. В 1С одна задача может решаться настройками НСИ, статусами документов, правилами обеспечения, механизмами согласования или типовыми отчётами.
3. Можно ли изменить сам процесс?
Иногда разрыв находится не между требованиями и системой, а между текущим процессом и целевой моделью бизнеса.
Если операция выполняется вручную только потому, что исторически не была автоматизирована, это ещё не означает, что ручной порядок нужно воспроизводить в новой системе.
4. Обязательно ли требование?
Следует отделять законодательные и критичные бизнес-требования от пользовательских предпочтений.
Отсутствие обязательного реквизита для формирования регламентированной отчётности — это существенный GAP. Непривычное расположение кнопки — скорее вопрос адаптации интерфейса.
5. Какова стоимость доработки и её дальнейшего сопровождения?
Любое изменение типовой конфигурации влияет не только на бюджет внедрения. Его потребуется тестировать при обновлениях, поддерживать и развивать вместе с системой.
Поэтому оценивать нужно полную стоимость владения решением, а не только первоначальные трудозатраты разработчика.
Что должно быть в реестре GAP
Для каждого предполагаемого разрыва необходимо зафиксировать:
- описание бизнес-требования;
- текущий порядок выполнения операции;
- возможности типовой 1С;
- выявленное расхождение;
- предлагаемое решение;
- критичность требования;
- необходимость доработки;
- оценку трудозатрат и рисков;
- ответственную сторону;
- принятое решение.
Такой реестр делает обсуждение прозрачным. Заказчик видит, почему конкретное требование предлагается реализовать настройкой, изменить на уровне процесса или передать в разработку.
Где поставить запятую
Оставить типовой функционал целесообразно, если он решает бизнес-задачу, обеспечивает необходимый контроль и позволяет получить требуемый результат — даже если последовательность действий отличается от привычной.
Доработка оправданна, если типовой механизм не покрывает обязательное законодательное требование, критичный отраслевой процесс или необходимую управленческую аналитику.
При этом решение должно приниматься совместно бизнесом, функциональным консультантом, архитектором и разработчиком. Пользователь понимает операционную потребность, консультант оценивает типовые возможности, архитектор — влияние на систему, а разработчик — техническую сложность.
Что получает бизнес
Грамотно проведённый GAP-анализ позволяет:
- контролировать бюджет внедрения;
- сократить количество необоснованных доработок;
- сохранить возможность безопасного обновления системы;
- определить приоритеты проекта;
- заранее выявить критические ограничения;
- избежать автоматизации неэффективных процессов.
Главная ценность GAP-анализа заключается не в поиске как можно большего количества расхождений. Его задача — найти оптимальный способ закрыть потребность бизнеса.
Не каждое отличие от старой системы требует разработки. Иногда нужно настроить 1С, иногда — изменить процесс, а иногда — отказаться от требования, которое больше не создаёт ценности.
Поэтому правильный вопрос на проекте звучит не «как повторить то, что было?», а «какой результат нужен бизнесу и как получить его с минимальной сложностью и рисками?»
Share
