Самописная учётная система на VB6 или Access: дорабатывать, переносить на .NET или переходить на ERP

В тысячах компаний учёт до сих пор ведёт программа, которую когда-то написал «свой программист»: формы на VB6 или Access, база в файле MDB или в SQL Server, отчёты в Crystal Reports и пара десятков выгрузок в Excel. Она годами работает без сбоев, точно повторяет процессы компании и ничего не стоит по лицензиям. Проблемы начинаются, когда автор уходит, база упирается в лимиты, а бизнесу нужны маркировка, интеграция с маркетплейсами или мобильный доступ для склада.

Тогда встаёт выбор: дорабатывать старое, переносить его на современную платформу, покупать коробочную ERP или заказывать разработку ERP-системы под свои процессы. Ошибка на этом шаге стоит дороже всего проекта: компания либо годами подгоняет себя под чужую конфигурацию, либо заново пишет такую же самописку, только на новом стеке. Ниже разбираем, как принять решение по фактам, а не по рекламным буклетам.

Если вопрос только в устаревшем коде, а функциональность устраивает, начните с нашего плана миграции VB6 на .NET и разбора стоимости миграции. Эта статья — о случае, когда под вопросом сама учётная модель.

Когда самописную учётную систему пора менять?

Возраст программы сам по себе не повод. Двадцатилетняя система, которую понимает команда и которая успевает за бизнесом, может работать ещё долго, если её сопровождать по правилам из статьи о сопровождении VB6. Повод для перехода — набор конкретных сигналов. Если совпадают три и больше, откладывать решение уже дороже, чем его принимать.

• Знания у одного человека. Логику расчёта себестоимости, бонусов или резервов понимает только автор. Он в отпуске — изменения стоят, он уволился — система заморожена.
• Упор в технические лимиты. Файл Access подбирается к пределу в 2 ГБ из спецификаций Access, при двадцати одновременных пользователях база «ломается» и сжимается по ночам, а драйвер Jet существует только в 32-битном варианте.
• Ручной двойной ввод. Данные из системы перебивают в бухгалтерскую программу, в CRM, в таблицы для склада. Каждый перенос — источник расхождений и часы работы.
• Новые требования регуляторов и партнёров. Электронный документооборот, маркировка, обмен с банками и маркетплейсами по API. Прикрутить это к VB6 можно, но каждая интеграция становится отдельным проектом.
• Нет удалённого и мобильного доступа. Склад, выездные сотрудники и руководство работают через удалённый рабочий стол или звонками в офис.
• Безопасность и аудит. Нет разграничения прав по ролям, журнала изменений, шифрования; пароль к базе лежит в INI-файле рядом с EXE. Внешний аудитор или служба безопасности начинают задавать неудобные вопросы.

Отдельный сигнал — среда разработки. Microsoft поддерживает среду выполнения VB6 в актуальных Windows по официальной политике, но IDE давно не поддерживается. Пока сборочная машина жива, это незаметно; когда она умирает, выясняется, что собрать проект заново никто не может.

Какие варианты есть: сравнение

Вариантов на самом деле пять, и у каждого есть своя честная ниша. Оценки ниже даны для типичной учётной системы среднего бизнеса: 50–150 форм, 30–80 отчётов, 20–60 пользователей.

На практике самый частый правильный ответ — гибрид. Бухгалтерию, зарплату и регламентированную отчётность бессмысленно писать заново: законодательство меняется несколько раз в год, и вендор коробки следит за этим за вас. А вот модуль, в котором зашит ваш способ планировать производство или считать цену для клиента, часто и есть то, за что самописку двадцать лет не выбрасывали.

Коробочная ERP или заказная: как выбрать?

Спор «коробка против разработки» обычно ведут на уровне лозунгов. Чтобы решение было обоснованным, пройдите по пяти вопросам и честно запишите ответы.

1. Какая доля процессов типовая? Возьмите перечень форм и отчётов из инвентаризации (о ней ниже) и разметьте: «есть в коробке из коробки», «есть с настройкой», «нужна доработка», «нет вообще». Если доработок больше трети, коробка перестаёт быть коробкой.
2. Где конкурентное преимущество? Если клиенты выбирают вас за скорость отгрузки или гибкие цены, а логика этого живёт в самописке, её нельзя упрощать ради типовой конфигурации.
3. Кто будет сопровождать? У массовых коробочных систем большой рынок специалистов. У заказной системы сопровождающий — подрядчик или своя команда, и это надо закладывать в бюджет на годы вперёд.
4. Сколько стоит владение за 3–5 лет? Сравнивайте не цену внедрения, а полную стоимость: лицензии, доработки, обновления конфигурации с доработками, сопровождение, инфраструктура. Заказная система дороже на старте, но без ежегодных лицензий и платы за переносы доработок при обновлениях.
5. Какие интеграции обязательны? Банки, ЭДО, маркетплейсы, сайт, мобильные приложения склада и торговых представителей. Проверьте, что есть готовое, а что придётся писать в любом варианте.

Что инвентаризировать в системе на VB6 и Access

Без инвентаризации нельзя ни выбрать вариант, ни сравнить предложения подрядчиков. Цель — получить полный список того, что система делает, и понять, что из этого реально используется. Обычно это занимает от одной до трёх недель.

• Таблицы и связи. Схема базы, справочники, документы, регистры остатков. Отдельно — связанные таблицы, которые смотрят в другие файлы MDB, Excel или ODBC-источники: о них часто никто не помнит.
• Формы и роли. Какие экраны открывают и кто именно. Опрос пользователей и логи (если их нет — простой счётчик открытий форм на месяц) обычно показывают, что треть форм мертва.
• Бизнес-логика. Модули VBA и VB6, хранимые процедуры, триггеры, макросы Access, запросы на изменение. Именно здесь живут правила расчёта, которые надо будет описать для новой системы.
• Отчёты и выгрузки. Отчёты Access и Crystal Reports, экспорт в Excel и файлы для банков. О замене отчётного слоя мы писали отдельно: чем заменить Crystal Reports.
• Интеграции и регламентные задания. Планировщик Windows, BAT-файлы, обмен через папки, почтовые рассылки.
• Обходные процессы. Таблицы Excel, которые пользователи ведут рядом с системой, потому что в ней чего-то не хватает. Это прямые требования к новой системе. Если такая таблица обросла макросами, посмотрите и наш разбор миграции VBA-макросов Excel.

Для Access первый срез объектов можно получить запросом к системной таблице прямо в самой базе. Он не заменяет анализ, но быстро показывает масштаб.

SELECT Switch(
         [Type]=1, "Таблица",
         [Type]=4, "Связанная ODBC",
         [Type]=6, "Связанная таблица",
         [Type]=5, "Запрос",
         [Type]=-32768, "Форма",
         [Type]=-32764, "Отчёт",
         [Type]=-32766, "Макрос",
         [Type]=-32761, "Модуль") AS ObjType,
       Count(*) AS Cnt
FROM MSysObjects
WHERE [Type] IN (1, 4, 5, 6, -32768, -32764, -32766, -32761)
  AND [Name] NOT LIKE "MSys*"
  AND [Name] NOT LIKE "~*"
GROUP BY [Type];

Для проекта VB6 аналог — перечень форм, модулей и подключённых OCX из файла VBP плюс поиск строк подключения и SQL-текстов по исходникам. Чек-лист того, что ещё стоит проверить в коде, — в статье об аудите legacy-кодовой базы.

Как перенести данные из Access и SQL Server без потерь?

Перенос данных — самый недооценённый этап любого перехода. В самописных системах за годы накапливается всё: дубли контрагентов, номенклатура с пробелами в конце, документы без проводок, даты 1899 года, справочники, которые меняли «прямо в таблице». Новая система с проверками целостности всё это не примет.

1. Решите, что переносить. Обычно это справочники, открытые документы и остатки на дату перехода. Полную историю за двадцать лет переносить дорого и редко нужно: её оставляют в старой базе в режиме только чтения, переведя на SQL Server.
2. Почистите справочники в старой системе. Дубли, неактуальные позиции, пустые реквизиты. Делать это в источнике дешевле, чем потом разбирать ошибки загрузки.
3. Составьте карту соответствий. Поле за полем: что куда переходит, как меняются коды, статусы и единицы измерения. Эту карту подписывают ключевые пользователи.
4. Поднимите промежуточную базу. Если данные в MDB, сначала перенесите их в SQL Server: SQL Server Migration Assistant для Access переносит схему и данные и заодно показывает проблемные типы и запросы. Дальше трансформации удобно писать на SQL.
5. Проведите пробные миграции. Минимум две-три полные пробные загрузки до боевой. Каждая заканчивается сверкой: количество записей, суммы остатков по счетам и складам, обороты за контрольный месяц.
6. Зафиксируйте дату и регламент отсечки. В какой момент старую систему переводят в режим только чтения, кто вводит документы «переходного» дня и как сверяют остатки на утро запуска.

Ключевое правило: критерии сверки согласуются до начала работ, а не после первой ошибки. Иначе каждое расхождение превращается в спор о том, какая из систем «считает правильно».

Как пройти переход по этапам

Переход на новую учётную систему за один день — самый рискованный сценарий. Устойчивая схема выглядит так:

1. Обследование и инвентаризация — 2–6 недель. Результат: перечень функций, разметка «типовое / уникальное», выбранный вариант и смета по этапам.
2. Проектирование целевой модели — описание процессов «как будет», а не «как было», с владельцем каждого процесса.
3. Пилот на одном контуре. Например, склад одного филиала или один участок производства. Пилот проверяет и систему, и подрядчика.
4. Интеграционный слой. Если старую систему выключают по частям, новая и старая какое-то время обмениваются данными. Мост проще всего делать через базу SQL Server или небольшой сервис с API поверх неё.
5. Поэтапный перенос контуров: склад, продажи, закупки, производство, финансы. Каждый контур — свои пробные миграции и приёмка.
6. Параллельная эксплуатация — 2–8 недель, когда операции ведутся в обеих системах и результаты сверяются. Это дорого для пользователей, но это единственный способ доказать, что новая система считает правильно.
7. Вывод старой системы: архивная копия в режиме только чтения, отключение регламентных заданий, обновление инструкций.
8. Гарантийный период и развитие: первые месяцы после запуска всплывают редкие сценарии — квартальное закрытие, годовая инвентаризация, нестандартные возвраты.

Хорошая проверка плана — спросить, что будет, если пилот провалится. Если ответа нет, план держится на надежде.

Сколько стоит и сколько длится переход?

Точную цифру даёт только смета по инвентаризации, но порядок можно оценить заранее. Для учётной системы среднего бизнеса проекты занимают от полугода до полутора лет; комплексный переход на крупную ERP — дольше и дороже. На бюджет сильнее всего влияют:

• Доля уникальной логики. Каждая доработка коробки или каждый нестандартный модуль заказной системы — это отдельные часы проектирования, разработки и тестов.
• Качество данных. Грязные справочники могут добавить к проекту месяцы.
• Число интеграций. Банки, ЭДО, маркетплейсы, сайт, сканеры и терминалы сбора данных.
• Обучение и сопротивление. Пользователи, двадцать лет работавшие в одной программе, привыкли к её горячим клавишам и обходам. Время ключевых пользователей на тесты и обучение — реальная статья затрат, даже если она не попадает в договор.
• Модель оплаты. Для таких проектов лучше всего работает фиксированная цена на обследование и пилот, а затем поэтапная смета: подробнее о моделях — в статье о бюджете миграции.

Окупаемость считают так же, как для любой миграции: годовая стоимость владения самопиской (зарплата или договор сопровождения, двойной ввод, ошибки, простои, риск потери единственного специалиста) против бюджета перехода и стоимости владения новой системой. Если самописка уже сейчас обходится дороже, переход окупается за несколько лет.

Как выбрать подрядчика для перехода?

Даже при выборе коробочной системы большую часть работы делает внешняя команда: обследование, перенос данных, интеграции, доработки. С самописками на VB6 и Access есть особенность — подрядчику нужно понимать и старый стек, и новый, иначе знания из исходников так и останутся неизвлечёнными. На переговорах полезно проверить:

1. Опыт чтения legacy-кода. Попросите разобрать один реальный модуль вашей системы и описать, что он делает. Это быстрее любых презентаций показывает уровень команды.
2. Подход к обследованию. Хороший подрядчик начинает с платного короткого этапа инвентаризации и не называет итоговую цену до него.
3. Методику миграции данных. Сколько пробных загрузок, какие критерии сверки, кто готовит эталоны.
4. Что остаётся у заказчика. Исходный код, документация, доступы к репозиторию и инфраструктуре, автотесты. Для заказной системы это условие независимости, для коробки — описание всех доработок конфигурации.
5. Сопровождение после запуска. Гарантийный срок, SLA и стоимость развития системы, а не только внедрения.

Если команда предлагает «переписать всё один в один за три месяца» без обследования, это сигнал остановиться: либо объём не понят, либо риски будут переложены на вас по ходу проекта.

Какие ошибки срывают переход?

• Выбор системы до инвентаризации. Демонстрация вендора выглядит убедительно, пока не выясняется, что половина ваших процессов в неё не ложится.
• Перенос всего подряд. Мёртвые формы, отчёты и двадцатилетняя история переносятся «на всякий случай» и съедают бюджет.
• Нет владельца процесса. Если за склад или себестоимость в новой системе никто не отвечает со стороны бизнеса, решения принимает подрядчик — и потом их же оспаривают.
• Автор самописки отстранён. Человек, который знает систему, — главный источник требований. Даже если он скептически относится к переходу, его время надо выделить и оплатить.
• Запуск без параллельной работы. Экономия нескольких недель оборачивается месяцами разбора расхождений в остатках.
• Новая самописка вместо ERP. Если заказная система пишется без документации, тестов и API, через десять лет компания окажется там же, где сейчас. Требуйте исходный код, описание архитектуры и автотесты как часть результата.

Как это делают сегодня

Вопросы и ответы