Клиенту нужно было вести 1С:Управление торговлей в облаке без покупки сервера и переплаты за лицензии на пики нагрузки. 1С:Фреш не подошел по функционалу
Этап 1. Анализ облачных вариантов
Первым кандидатом для переноса в облако был 1С:Фреш как официальный сервис от фирмы 1С. Логика была простой: использовать знакомый бренд и типовой облачный продукт.
Однако сразу выяснилось ключевое ограничение: 1С:Фреш не поддерживает конфигурацию 1С:Управление торговлей, которую использует компания. Сервис ориентирован на типовые конфигурации, такие как Бухгалтерия и Управление нашей фирмой, а специализированная конфигурация управления торговлей в этом перечне отсутствует.
Для компании это означало бы:
- отказ от привычной модели учета товаров, заказов, складов и аналитики;
- переобучение всех пользователей на другую конфигурацию;
- пересмотр и перестройку внутренних процессов;
- отказ от части привычных отчетов и доработок.
Менять рабочие бизнес-процессы и функциональность только ради того, чтобы «поместиться» в рамки типового облачного сервиса, руководитель счел неправильным. Поэтому 1С:Фреш был исключен из рассмотрения по объективным техническим причинам.
Этап 2. Формулировка требований к альтернативе
После отказа от 1С:Фреш требования к облачному решению были зафиксированы более формально. Новое решение должно было:
- Поддерживать конфигурацию 1С:Управление торговлей без необходимости перехода на другую конфигурацию.
- Обеспечивать стабильную работу при росте нагрузки с 12–15 до 25–26 одновременных пользователей.
- Позволять компании самостоятельно управлять доступом аутсорсинговой бухгалтерии к базе, в том числе быстро закрывать доступ при смене подрядчика.
- Давать возможность оплачивать ресурсы исходя из фактического использования, а не по «верхнему пределу» на весь год.
На этом этапе стало понятно, что нужен сервис, который работает с полноценными конфигурациями 1С и соответствует требованиям по гибкости и управляемости.
Этап 3. Внедрение облачного решения Альтап
В качестве подходящего варианта был выбран облачный сервис Альтап, который позволяет размещать конфигурации 1С в том виде, в котором они уже используются у клиента, без переделок. Для компании это означало, что 1С:Управление торговлей можно перенести в облако «как есть», не меняя логику работы и не переписывая доработки.
Внедрение было разбито на несколько шагов.
Шаг 1. Миграция базы (4 часа)
База 1С:Управление торговлей была перенесена в облако в исходном виде. Сохранились все подсистемы, справочники, отчеты, роли пользователей и существующие доработки. Это позволило сотрудникам продолжить работу в уже знакомом интерфейсе и с привычными процессами.
Шаг 2. Настройка прав и доступа (1 час)
Далее были настроены права для сотрудников компании и аутсорсинговой бухгалтерии. Для внешней бухгалтерской фирмы выделили отдельную базу 1С:Бухгалтерия, а доступ к ней клиент теперь может выдавать и отзывать самостоятельно. Это сняло зависимость от технических специалистов при управлении доступами.
Шаг 3. Тестовый период (1 неделя)
Перед окончательным переходом была проведена проверка работы системы в двух режимах:
- в штатном режиме с 12–15 пользователями;
- под нагрузкой с 26 одновременными сеансами.
В обоих сценариях система работала стабильно, без задержек и подвисаний, время отклика оставалось комфортным для работы с документами.
Шаг 4. Переход в промышленную эксплуатацию
После удачного тестирования сотрудники перешли на работу в облаке. Отдельно отметили, что удаленным пользователям стало удобнее работать: доступ к базе осуществляется напрямую через облако, без необходимости подключаться к офисному серверу.
Этап 4. Работа в облаке и контроль затрат
В повседневной работе облачная модель показала себя более предсказуемой как по качеству работы, так и по расходам.
В обычные дни система обслуживает 12–15 пользователей без каких-либо проблем с производительностью. В периоды пиковых нагрузок количество сеансов увеличивается до 25–26, при этом пользователи не ощущают снижения скорости работы.
Отдельное преимущество для компании дало использование подневного учета работы пользователей. Руководитель теперь видит, сколько людей и в какие дни реально работали в системе, и понимает, как формируются расходы:
- в обычные периоды оплата соответствует числу активных пользователей;
- в пиковые дни стоимость возрастает пропорционально росту числа сеансов, но только на эти конкретные даты;
- после завершения пика расходы автоматически снижаются вместе с уменьшением нагрузки.