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?"
Книга Карла Вигерса и Джой Битти «Разработка требований к программному обеспечению» считается одним из фундаментальных руководств по работе с требованиями. Она предназначена для бизнес-аналитиков, разработчиков, руководителей проектов и всех специалистов, участвующих в создании и внедрении информационных систем.
Лично мне книга понравилась. Она помогает систематизировать знания и посмотреть на разработку требований не как на формальное составление технического задания, а как на полноценный процесс взаимодействия между бизнесом и IT-командой.
Требование — это не просто пожелание пользователя
Одна из главных мыслей книги заключается в том, что требование должно отражать реальную потребность бизнеса.
На практике пользователи часто формулируют уже готовое решение:
- добавьте новое поле;
- создайте отдельный документ;
- измените печатную форму;
- сделайте такой же отчёт, как в прежней системе;
- перенесите привычный процесс без изменений.
Однако задача аналитика — не просто зафиксировать пожелание, а выяснить, какую проблему пользователь пытается решить и какой результат ожидает получить.
Именно этот подход особенно полезен при внедрении 1С. За фразой «нам нужна доработка» может скрываться отсутствие настройки, непонимание типового механизма или нежелание менять устоявшийся бизнес-процесс.
Что показалось наиболее полезным
Авторы подробно рассматривают весь цикл работы с требованиями: от их выявления и формулирования до согласования, проверки, приоритизации и управления изменениями.
Особенно полезными для меня стали следующие идеи:
- необходимо разделять бизнес-требования, пользовательские требования и функциональные требования;
- требования должны быть однозначными, полными, согласованными и проверяемыми;
- разные группы пользователей могут по-разному видеть один и тот же процесс;
- согласованное требование не становится неизменным — им необходимо управлять на протяжении всего проекта;
- изменение одного требования может повлиять на несколько связанных процессов и объектов системы;
- аналитик должен не только собирать информацию, но и выявлять противоречия, риски и недостающие данные.
Эти принципы напрямую применимы при подготовке опросников, проведении интервью, описании бизнес-процессов, формировании технических заданий и реестров функциональных разрывов.
Книга также хорошо показывает, почему нельзя начинать разработку на основании одной короткой фразы заказчика. Если требование не проанализировано и не согласовано, команда может технически правильно реализовать функцию, которая не решает первоначальную задачу бизнеса.
Какие методы выглядят устаревшими
Несмотря на практическую ценность книги, некоторые подходы сегодня воспринимаются как достаточно тяжеловесные.
Книга предлагает большое количество документов, шаблонов, согласований и формальных процедур. Для крупных проектов со сложной архитектурой, высоким уровнем риска и большим числом заинтересованных сторон такой подход может быть оправдан.
Но на небольших проектах или при использовании гибких методологий полное применение всех предложенных инструментов способно замедлить работу. Современные команды чаще используют короткие итерации, прототипирование, демонстрации, совместные обсуждения и последовательное уточнение требований.
Кроме того, с момента выхода третьего издания существенно изменились инструменты аналитика. Сегодня требования могут храниться в специализированных системах, связываться с задачами разработки и тестирования, автоматически проверяться и анализироваться с помощью ИИ.
Поэтому некоторые методы книги, на мой взгляд, стоит применять избирательно и адаптировать под масштаб конкретного проекта.
При этом устарели скорее отдельные формы работы, а не основные принципы. Понимание потребности заказчика, проверяемость требований, управление изменениями и ответственность сторон остаются актуальными независимо от используемой методологии.
Как книга связана с проектами внедрения 1С
При внедрении 1С особенно важно отделять реальное требование бизнеса от привычки пользователя работать определённым способом.
Например, заказчик просит разработать отчёт, полностью повторяющий форму из предыдущей системы. Аналитик должен определить:
- какие показатели используются в отчёте;
- из каких данных они формируются;
- для принятия каких решений необходимы;
- существуют ли эти показатели в типовых отчётах 1С;
- можно ли получить результат с помощью настройки;
- действительно ли требуется разработка новой формы.
Подход, описанный Вигерсом и Битти, помогает перевести пожелание пользователя в понятное, обоснованное и проверяемое требование.
Это снижает риск лишних доработок, неконтролируемого расширения границ проекта и конфликтов между заказчиком и исполнителем.
Кому будет полезна книга
Я бы рекомендовала её:
- начинающим бизнес- и системным аналитикам;
- функциональным консультантам 1С;
- руководителям проектов;
- разработчикам, которые участвуют в обсуждении требований;
- представителям заказчика, отвечающим за автоматизацию;
- специалистам, готовящим технические задания и проектную документацию.
Новичкам книга поможет сформировать системное представление о работе с требованиями. Опытные специалисты смогут сравнить предложенные методы со своей практикой и выбрать инструменты, подходящие для конкретных проектов.
Итоговое впечатление
«Разработка требований к программному обеспечению» — объёмная и местами непростая книга. Некоторые описанные методы требуют адаптации к современным инструментам и гибким форматам работы.
Тем не менее книга остаётся очень полезной. Она учит задавать правильные вопросы, видеть за пожеланиями пользователей реальные потребности бизнеса и понимать последствия каждого изменения.
Для меня её главная ценность заключается не в готовых шаблонах, а в формировании аналитического мышления.
Методы могут меняться, документы — становиться короче, а инструменты — технологичнее. Но необходимость услышать заказчика, правильно понять его задачу и сформулировать проверяемое требование остаётся неизменной.
Share
