Разработка на 1С: заявлено 100% выполнения, фактически подтверждено 58%

Ситуация
Заказчик заключил договор на разработку и доработку системы на базе 1С для автоматизации внутренних бизнес-процессов: заявок, согласований, отчётности и разграничения доступа между подразделениями.
Исполнитель передал результат и заявил, что работы выполнены в полном объёме. Общая стоимость проекта составляла 8,8 млн рублей. Заказчик отказался подписывать финальный акт, поскольку при эксплуатации выяснилось, что значительная часть функций либо отсутствует, либо работает только в демонстрационном режиме.

Задача экспертизы
Необходимо было установить, соответствует ли разработанная конфигурация 1С техническому заданию, а также определить фактический объём выполненных работ.

Что исследовалось
Экспертами были проанализированы:

• договор и техническое задание на 47 функциональных требований;
• конфигурация 1С;
• база данных;
• пользовательские роли;
• отчёты, формы, обработки и регламентные задания;
• переписка сторон;
• акты сдачи-приёмки;
• замечания заказчика по результатам тестирования.

Что было установлено
Из 47 требований технического задания:

• 21 требование было выполнено полностью;
• 13 требований выполнены частично;
• 9 требований не были реализованы;
• 4 требования присутствовали в интерфейсе, но фактически не выполняли заявленную функцию.

Например, в системе имелась форма согласования заявки, однако маршрут согласования не менялся в зависимости от суммы заявки, как было предусмотрено ТЗ. При сумме до 100 000 рублей заявка должна была проходить 2 этапа согласования, при сумме свыше 100 000 рублей — 4 этапа. Фактически система во всех случаях запускала один и тот же маршрут.
Также было установлено, что отчёты по подразделениям формировались только при ручном заполнении части реквизитов. Автоматическое подтягивание данных из связанных документов, предусмотренное техническим заданием, отсутствовало.

Итоговый вывод
Фактическая степень выполнения работ была оценена в 58%. При этом часть реализованных функций не могла использоваться в рабочем процессе без доработки.

Определение объёма выполненных работ: из 12 модулей полноценно работали только 5

Ситуация
Исполнитель разрабатывал корпоративную информационную систему для обработки заказов, документооборота и аналитики. Проект был разбит на 4 этапа и включал 12 функциональных модулей.
После завершения работ исполнитель заявил о готовности продукта и потребовал оплатить оставшуюся часть договора. Заказчик указал, что система не может быть введена в промышленную эксплуатацию, поскольку критически важные модули не завершены.

Задача экспертизы
Перед экспертами стояла задача определить фактическую степень готовности программного продукта и установить, какие работы действительно выполнены.

Что исследовалось
В рамках экспертизы были проверены:

• техническое задание;
• исходный код;
• база данных;
• демонстрационная версия системы;
• пользовательская документация;
• акты по этапам;
• переписка по замечаниям;
• результаты пользовательского тестирования.

Что было установлено
Из 12 заявленных модулей:

• 5 модулей работали в соответствии с ТЗ;
• 3 модуля были реализованы частично;
• 2 модуля находились в состоянии прототипа;
• 2 модуля отсутствовали как самостоятельный функциональный блок.

Наиболее существенные недостатки были выявлены в модулях:
1. Модуль аналитики
Должен был формировать 8 видов отчётов. Фактически корректно формировались только 3 отчёта. В 2 отчётах данные не совпадали с базой, ещё 3 отчёта отсутствовали.
2. Модуль документооборота
Должен был обеспечивать создание, согласование и хранение документов. Фактически документы создавались, но не проходили полный маршрут согласования, а история изменений не сохранялась.
3. Модуль уведомлений
По ТЗ система должна была отправлять уведомления в email и личный кабинет. Фактически email-уведомления не отправлялись, а уведомления в личном кабинете появлялись только после ручного обновления страницы.

Итоговый вывод
Экспертиза установила, что программный продукт был готов ориентировочно на 62%. При этом готовность отдельных модулей существенно различалась: от полностью работоспособных до фактически отсутствующих.

Оценка стоимости фактически выполненной разработки: из 6,2 млн рублей подтверждено работ на 3,1 млн

Ситуация
Заказчик оплатил разработку программного продукта общей стоимостью 6,2 млн рублей. Исполнитель передал систему и заявил, что основная часть работ выполнена, а оставшиеся замечания являются несущественными.
Заказчик считал, что переданный результат нельзя использовать по назначению, поскольку часть ключевых функций отсутствует, а часть требует существенной переработки.

Задача экспертизы
Необходимо было определить стоимость фактически выполненных работ, отделив реально созданный результат от незавершённых, дефектных и непригодных к эксплуатации функций.

Что исследовалось
Эксперты анализировали:

• договорную стоимость проекта;
• структуру этапов;
• техническое задание;
• состав реализованного функционала;
• исходный код;
• архитектуру системы;
• сложность модулей;
• трудозатраты на аналогичные работы;
• пригодность результата к эксплуатации.

Что было установлено
В техническом задании было выделено 9 функциональных блоков:

1. авторизация и роли пользователей;
2. личный кабинет;
3. каталог объектов;
4. модуль заявок;
5. модуль согласований;
6. отчётность;
7. интеграция с CRM;
8. уведомления;
9. административная панель.

По результатам исследования:

• 4 блока были выполнены в рабочем состоянии;
• 3 блока имели существенные ограничения;
• 2 блока фактически отсутствовали либо были представлены в виде заготовок.

Например, административная панель позволяла создавать пользователей, но не позволяла управлять правами доступа по ролям. Модуль заявок создавал записи в базе, но не передавал их в CRM. Отчётность была реализована частично: из 11 предусмотренных показателей корректно рассчитывались только 6.

Расчёт стоимости
С учётом фактической реализации и самостоятельной ценности модулей было установлено, что технически подтверждённый объём работ соответствует примерно 50–52% от договорного объёма.
При стоимости договора 6,2 млн рублей стоимость фактически выполненных работ была оценена ориентировочно в 3,1–3,2 млн рублей.

Итоговый вывод
Не весь написанный код имел самостоятельную ценность для заказчика. Часть модулей существовала формально, но не обеспечивала выполнение согласованных бизнес-сценариев.

Сравнение исходных кодов: совпадение 34%, включая уникальные фрагменты и одинаковые ошибки

Ситуация
Компания обнаружила, что программный продукт конкурента имеет значительное сходство с ранее разработанной системой. Возник спор о возможном незаконном использовании исходного кода.
Ответчик утверждал, что разработка была выполнена самостоятельно, а совпадения объясняются использованием одинаковых библиотек и типовых решений.

Задача экспертизы
Необходимо было установить, имеются ли совпадения между двумя программными продуктами, каков их объём и характер, а также могут ли они свидетельствовать о заимствовании.

Что исследовалось
Экспертами были проанализированы:

• исходные коды двух программных продуктов;
• структура каталогов;
• наименования файлов;
• классы, методы и функции;
• комментарии разработчиков;
• алгоритмы обработки данных;
• конфигурационные файлы;
• служебные скрипты;
• повторяющиеся ошибки и нетиповые технические решения.

Что было установлено
Общее совпадение по массиву исследованного кода составило около 34%. При этом наиболее значимые совпадения были выявлены не в типовых библиотеках, а в пользовательских модулях.
Например:

• в модуле расчёта статусов совпадение составило 71%;
• в модуле формирования отчётов — 64%;
• в модуле обработки заявок — 58%;
• в служебных скриптах миграции данных — 46%.

Отдельное значение имело совпадение комментариев и технических ошибок. В обоих продуктах были обнаружены одинаковые устаревшие комментарии, одинаковые названия временных переменных и одинаковая ошибка в обработке пустого значения при расчёте статуса заявки.
Такие совпадения не характерны для независимой разработки, особенно если они касаются не стандартных шаблонов, а индивидуальной бизнес-логики.

Итоговый вывод
Экспертиза установила наличие существенных совпадений в индивидуальных фрагментах программного кода. При этом часть совпадений не могла быть объяснена использованием типовых библиотек, фреймворков или стандартных решений.

Интеграция с CRM и 1С: данные передавались только по 6 из 17 обязательных сценариев

Ситуация
Исполнитель должен был разработать сайт и реализовать интеграцию с CRM и 1С. По договору система должна была автоматически передавать заявки, статусы, счета, контрагентов, товары, остатки и сведения об оплате.
После запуска заказчик обнаружил, что менеджеры продолжают переносить значительную часть данных вручную. Исполнитель утверждал, что интеграция выполнена, поскольку соединение между системами настроено и отдельные данные передаются.

Задача экспертизы
Необходимо было установить, соответствует ли интеграция техническому заданию и обеспечивает ли она выполнение согласованных бизнес-сценариев.

Что исследовалось
В рамках экспертизы были проверены:

• техническое задание на интеграцию;
• API-документация;
• настройки CRM;
• настройки обмена с 1С;
• логи запросов;
• JSON/XML-файлы обмена;
• обработчики событий;
• регламентные задания;
• тестовые сценарии передачи данных.

Что было установлено
Техническое задание предусматривало 17 сценариев обмена данными.
Фактически:

• 6 сценариев работали корректно;
• 5 сценариев работали частично;
• 4 сценария завершались ошибками;
• 2 сценария отсутствовали полностью.

Например, заявка с сайта действительно передавалась в CRM, но без части обязательных полей: не передавался источник обращения, комментарий клиента и выбранный объект. Из-за этого менеджер не мог полноценно обработать заявку без ручного уточнения данных.
Передача статусов из CRM обратно на сайт работала только для 2 из 5 предусмотренных статусов. Статусы «счёт выставлен», «оплата получена» и «заказ закрыт» не отображались в личном кабинете пользователя.
Интеграция с 1С также была реализована частично. Остатки товаров обновлялись раз в сутки вместо предусмотренного обновления каждые 30 минут. Счета создавались, но не связывались с соответствующим заказом в CRM.

Итоговый вывод
Экспертиза установила, что интеграция была реализована не полностью. Наличие технического соединения между системами не подтверждало выполнение обязательства, поскольку большинство согласованных бизнес-сценариев не работали либо требовали ручного вмешательства.
Фактическая готовность интеграционного блока была оценена в 45%.

Рецензирование экспертного заключения: выявлено 11 существенных методических недостатков

Ситуация
В судебном деле уже имелось экспертное заключение, в котором было указано, что программный продукт соответствует условиям договора, а работы выполнены в полном объёме.
Одна из сторон не согласилась с такими выводами, поскольку в заключении отсутствовало подробное описание проверок, не были раскрыты тестовые сценарии, а выводы эксперта противоречили отдельным материалам дела.

Задача экспертизы
Необходимо было проверить, является ли экспертное заключение полным, обоснованным и технически проверяемым. Также требовалось установить, можно ли на основании такого заключения делать категоричный вывод о полном соответствии программного продукта договору.

Что исследовалось
Рецензентом были проанализированы:

• экспертное заключение;
• вопросы, поставленные перед экспертом;
• договор;
• техническое задание;
• акты;
• исследовательская часть заключения;
• выводы эксперта;
• перечень фактически проведённых проверок;
• соответствие выводов установленным обстоятельствам.

Что было установлено
В заключении было выявлено 11 существенных недостатков, в том числе:

1. Эксперт указал на соответствие продукта договору, но не проверил 18 из 43 требований технического задания.
2. В заключении отсутствовали тестовые сценарии, по которым проверялась работоспособность функций.
3. Эксперт сделал вывод о выполнении интеграции, но не привёл ни одного примера фактической передачи данных между системами.
4. Проверка ограничилась демонстрационной базой, тогда как спор касался работоспособности системы в рабочем контуре заказчика.
5. В заключении были описаны интерфейсы, но не была проверена фактическая логика обработки данных.
6. Не были исследованы логи ошибок, хотя в материалах дела имелись указания на системные сбои.
7. Отсутствовала проверка ролей пользователей и прав доступа.
8. Эксперт не разграничил полностью выполненные и частично выполненные требования.
9. Не была дана оценка замечаниям заказчика, направленным исполнителю до подписания акта.
10. В исследовательской части были зафиксированы отдельные ограничения системы, но в выводах они не были учтены.
11. Итоговый вывод о 100% выполнении работ не был подтверждён расчётом, таблицей соответствия или иной проверяемой методикой.

Итоговый вывод
Рецензирование показало, что выводы экспертного заключения не следуют однозначно из исследовательской части. Заключение содержало признаки неполноты исследования и не позволяло проверить, каким образом эксперт пришёл к выводу о полном соответствии работ условиям договора.