АРМ — автоматизированное рабочее место: что это и как внедряют
Автоматизированное рабочее место — это не новый компьютер у сотрудника, а экран, где собраны данные и действия для его роли: заказы, остатки, клиенты, документы. Одни компании получают такое место настройкой учётной системы, другие заказывают отдельное приложение, и разница между путями — в сроках, цене и глубине подстройки под процесс. Дальше — из чего состоит АРМ, какие бывают виды, как проходит внедрение от обследования до пилота и где при этом чаще всего теряют время.
Что такое АРМ простыми словами
Картина, знакомая многим компаниям: чтобы подтвердить один заказ, оператор открывает учётную систему, CRM с историей клиентов, таблицу с остатками и мессенджер со складом. Данные переносятся вручную, ошибки находят покупатели, а новичок учится этому месяц.
Автоматизированное рабочее место, или АРМ, — это набор экранов, данных и действий, собранный под одну роль в компании. Оператор видит заказ, остатки, историю клиента и кнопку «Подтвердить» на одном экране. Кладовщик сканирует штрихкод и сразу получает ячейку хранения. Руководитель открывает показатели отдела без выгрузок в таблицы.
Термин пришёл из российских стандартов на автоматизированные системы (серия ГОСТ 34), где АРМ описан как часть системы, через которую с ней работает человек.
| Параметр работы | Рабочее место с набором программ | Автоматизированное рабочее место |
|---|---|---|
| Сколько окон на одну операцию | 3–6 программ и таблиц, данные переносятся вручную | Один экран, данные подтягиваются из систем автоматически |
| Кто задаёт порядок действий | Сотрудник по памяти или по инструкции | Сценарий на экране: следующий шаг открыт только после предыдущего |
| Проверка ошибок | После операции, силами коллег или покупателей | В момент ввода: поле не примет несуществующий артикул или адрес |
| Доступ к данным | Общий доступ к системам, часто шире, чем нужно роли | Права по роли и журнал действий: видно, кто и что изменил |
| Отчётность руководителю | Выгрузки и сводные таблицы раз в неделю | Показатели считаются из операций в реальном времени |
АРМ не заменяет учётную систему, CRM или ERP (систему планирования ресурсов предприятия): они хранят данные и правила всей компании, а АРМ — окно в них для конкретного сотрудника, иногда сразу в три-четыре системы. Как выбрать саму CRM, разобрано в статье о видах CRM-систем, а внутренние сервисы компании в целом — в материале о корпоративном портале.

Из чего состоит автоматизированное рабочее место
Снаружи АРМ выглядит как одна программа, но внутри у него четыре слоя.
Интерфейс под роль
Экраны, где собраны только нужные роли данные и действия. Их проектируют от частоты операций: то, что делают сто раз в смену, доступно в одно касание, редкие настройки спрятаны глубже. Подход описан на странице UX/UI-дизайна.
Данные и справочники
Номенклатура, клиенты, адреса, цены, статусы. Справочники АРМ должны совпадать со справочниками учётной системы, иначе через месяц появятся два списка складов и два написания одного клиента. Поэтому на старте для каждого справочника назначают главную систему.
Интеграции
Обмен с 1С, складской системой, CRM, телефонией, службами доставки, эквайрингом. Интеграции чаще всего и определяют срок проекта: состояние чужих систем и доступ к ним от команды разработки не зависят. Типовые сценарии — на страницах ERP-интеграции и интеграции с CRM, принципы описания обмена — в статье о проектировании REST API.
Права, журнал действий и защита данных
Ролевая модель определяет, кто что видит и меняет, журнал фиксирует, кто отменил заказ или изменил цену. Если в АРМ есть персональные данные, требования к ним задаёт Федеральный закон № 152-ФЗ «О персональных данных»; конкретные меры для вашей компании определяют служба безопасности и юрист до начала проектирования.

Виды АРМ: по ролям и по исполнению
Практичнее всего делить АРМ по ролям: под роль и собирают экраны. Бухгалтеру и кадровику обычно хватает типовых конфигураций учётных систем, а отдельную разработку заказывают для ролей на стыке нескольких систем.
| Роль | Типовые операции | С какими системами связан | Устройство |
|---|---|---|---|
| Оператор заказов и контакт-центра | Приём и подтверждение заказов, статусы, звонки клиентам, возвраты | Учётная система, CRM, телефония, служба доставки | Компьютер, иногда два монитора |
| Кладовщик и сборщик | Приёмка, размещение, сборка, инвентаризация по штрихкоду | Складская система (WMS — система управления складом), 1С | Терминал сбора данных на Android |
| Менеджер B2B-продаж | Карточка клиента, прайс и остатки, коммерческое предложение, заказ на юрлицо | CRM, 1С, почта, электронный документооборот | Ноутбук, планшет |
| Контент-менеджер и маркетолог | Карточки товаров, баннеры, подборки, акции и рассылки | Административная панель сайта и приложения, CRM | Компьютер, веб-интерфейс |
| Выездной сотрудник | Маршрут, фотоотчёт, подпись клиента, работа без связи | Учётная система, карты и геолокация | Смартфон или планшет |
| Руководитель подразделения | Показатели, согласования, отклонения от плана | Данные из всех систем подразделения | Веб-панель, смартфон |
По исполнению АРМ бывает программой на компьютере (для интенсивной работы с клавиатурой), веб-кабинетом (без установки, удобно при большом числе сотрудников), мобильным приложением (для выездных ролей и торгового зала) и приложением для терминала сбора данных на складе.
Кроссплатформенный Flutter позволяет собрать программу для Windows, macOS и Linux, веб-версию и мобильное приложение из одной кодовой базы: АРМ менеджера и АРМ сборщика используют общую логику и одинаковые правила проверки данных. Подробнее — на страницах кроссплатформенной разработки на Flutter и корпоративных приложений. Для служебных устройств есть штатные инструменты: Android позволяет настраивать приложение централизованно, а Apple — распространять его только внутри компании.

Когда компании нужен АРМ, а когда хватит настройки
Шесть признаков, что компании нужен АРМ:
- Одна операция — несколько программ. Номер заказа копируют из системы в систему, остатки сверяют в таблице, складу пишут в мессенджер.
- Ошибки находят клиенты. Пересорт, неверный адрес, забытая позиция — и каждая ошибка стоит повторной доставки или возврата.
- Новичок выходит на полную скорость неделями. Порядок действий живёт в голове опытных сотрудников, а не в интерфейсе.
- Руководитель собирает отчёт вручную. Показатели появляются раз в неделю, когда исправлять поздно.
- Рост упирается в людей. Вдвое больше заказов требует вдвое больше операторов.
- Доступы шире, чем нужно. Склад видит закупочные цены, оператор может изменить любую карточку товара.
Если роль работает в одной системе и мешают только лишние поля и кнопки, отдельная разработка не нужна: хватает настройки прав и интерфейса в самой системе. Об автоматизации учёта средствами учётной системы — в статье об автоматизации учёта товара в 1С. Выбрать путь помогает короткое обследование процессов бизнес-аналитиком: оно показывает, где теряется время, до появления сметы.
Четыре способа получить АРМ
У каждого пути своя сильная сторона. Сроки — ориентиры по нашему опыту для первой роли; точные цифры появляются после технического задания.
| Способ | Где подходит | Срок до первой версии | Чем приходится платить |
|---|---|---|---|
| Типовая конфигурация учётной системы | Бухгалтерия, кадры, склад со стандартным процессом | 10–40 рабочих дней на настройку | Процесс подстраивается под программу; нестандартные операции остаются в таблицах |
| Доработка существующей системы | Роль работает в одной системе, не хватает нескольких форм и отчётов | 20–60 рабочих дней | Зависимость от версии системы: каждое обновление требует проверки доработок |
| Заказная разработка отдельного АРМ | Роль на стыке нескольких систем, мобильные и складские сценарии, нестандартный процесс | 65–175 рабочих дней до пилота | Бюджет и срок старта больше, чем у трёх других путей; нужны поддержка и развитие после запуска |
| Конструктор без программирования (no-code) | Простая форма заявки или согласования, проверка гипотезы | 5–20 рабочих дней | Ограничения конструктора по интеграциям, нагрузке и офлайн-работе |
Типовые пути быстрее и дешевле на старте, заказная разработка точнее повторяет процесс. На практике их сочетают: бухгалтерия работает в типовой конфигурации, а для операторов и склада собирают отдельные рабочие места поверх той же учётной системы. Сравнение по стоимости владения — в статьях о подписочных сервисах и собственной разработке и о разработке корпоративных систем.
Как внедряют АРМ: карта этапов
Внедрение проходит шесть этапов до запуска у всех сотрудников роли, плюс поддержка после. Главное отличие от разработки обычного приложения — пилот: новое рабочее место сначала получает одно подразделение, и только после замеров его тиражируют.
| Этап | Рабочих дней | Результат, который можно проверить |
|---|---|---|
| 1. Обследование процессов и ролей | 5–15 | Карта процессов, список операций, замеры времени «до» |
| 2. Требования и техническое задание | 10–20 | Подписанное ТЗ с ролями, интеграциями и составом первой версии |
| 3. Проектирование экранов и обмена данными | 10–20 | Прототип, проверенный на сотрудниках, и схема обмена данными |
| 4. Разработка первой версии и интеграции | 40–120 | Сборка на тестовом окружении, подключённая к копии учётной системы |
| 5. Пилот в одном подразделении | 10–20 | Отчёт пилота с замерами «до и после» и списком правок |
| 6. Тиражирование, обучение и перенос данных | 10–30 | АРМ у всех сотрудников роли, инструкции, обученные ключевые пользователи |
Последовательно шесть этапов складываются в 85–225 рабочих дней, это примерно 4–11 месяцев. Этапы 2 и 3 частично идут одновременно — прототип собирают, пока дописывают требования к интеграциям, — и это экономит 5–10 рабочих дней. Первая версия на пилоте появляется через 65–175 рабочих дней.

Этап 1. Обследование процессов и ролей
Что происходит: аналитик проводит день рядом с сотрудниками будущей роли, записывает каждую операцию и считает, сколько она занимает. Задача — увидеть фактический процесс, а не тот, что описан в регламенте.
Что входит в этап
- Интервью с сотрудниками роли, их руководителем и ИТ-службой.
- Хронометраж пяти–десяти частых операций.
- Список систем, справочников и ручных переносов данных.
- Типовые ошибки и их стоимость: возвраты, повторные доставки, штрафы.
Результат этапа
Карта процессов «как есть» с замерами времени и списком потерь. Без замеров на пилоте не с чем будет сравнивать новое рабочее место.
Проверьте перед следующим этапом
- Известно, сколько сотрудников в роли и сколько операций они делают в смену?
- Для пяти частых операций есть замер времени?
- Назван владелец процесса со стороны бизнеса, который принимает решения?
Типичная ошибка на этом этапе
Описывать процесс со слов руководителя. В регламенте заказ подтверждают в учётной системе, а на деле — звонком складу и отметкой в общей таблице. Если это не увидеть, АРМ автоматизирует процесс, которого не существует.
Этап 2. Требования и техническое задание
Что происходит: карта процессов превращается в описание будущей работы: какие экраны нужны роли, какие данные на них, откуда они приходят и куда уходят. Здесь же решают, что войдёт в первую версию.
Что входит в этап
- Пользовательские сценарии для каждой операции роли.
- Ролевая модель: кто что видит, меняет и согласует.
- Список интеграций с главной системой для каждого справочника.
- Требования к работе без связи, нагрузке и защите данных.
- Граница ответственности: кто даёт доступы, тестовые данные и оборудование.
Результат этапа
Техническое задание — основание для сметы, приложение к договору и документ для приёмки. Его можно заказать отдельно как разработку технического задания и передать любому подрядчику. Место ТЗ в полном цикле — в статье об этапах разработки ПО.
Проверьте перед следующим этапом
- В первой версии одна-две роли, а не все подразделения сразу?
- Описано, что делает сотрудник, если связи с сервером нет?
- Служба безопасности согласовала требования к данным?
Типичная ошибка на этом этапе
Включить в первую версию все роли и все пожелания. Объём растёт вдвое, пилот уезжает на полгода, а сотрудники всё это время работают по-старому.
Этап 3. Проектирование экранов и обмена данными
Что происходит: дизайнер собирает кликабельный прототип и проверяет его на трёх–пяти сотрудниках роли. Архитектор описывает обмен данными с учётной системой, CRM и складом: состав запросов, частоту обновления и поведение при сбое.
Что входит в этап
- Прототип основных экранов по сценариям из технического задания.
- Проверка прототипа на сотрудниках: где ищут кнопку, где ошибаются.
- Схема обмена данными и порядок синхронизации справочников.
- Решение по устройствам и размещению: серверы компании или облако.
Результат этапа
Прототип, прошедший проверку на сотрудниках, и схема обмена данными. С ними смета становится планом работ. Методы проверки на пользователях — в статье об UX-исследованиях, проверку действующей системы делает аудит UX/UI.
Проверьте перед следующим этапом
- Сотрудники прошли частые операции на прототипе без подсказок?
- Описано поведение АРМ, если учётная система недоступна?
- Устройства выбраны под сценарий, а не наоборот?
Типичная ошибка на этом этапе
Согласовывать экраны только с руководителем. Он смотрит на отчёты, а сотрудник — на скорость ввода и число переключений. Без проверки на тех, кто работает в АРМ каждый день, интерфейс получается удобным для презентации.
Этап 4. Разработка первой версии и интеграции
Что происходит: команда разрабатывает экраны, серверную часть и подключения к внешним системам итерациями по одной-две недели. После каждой итерации владелец процесса открывает сборку и проверяет сам, а инженер по тестированию проверяет готовые части сразу, а не в последнюю неделю.
Что входит в этап
- Серверная часть: хранение данных, права доступа, журнал действий.
- Экраны роли и интеграции с учётной системой, CRM, складом, телефонией.
- Работа без связи и синхронизация, если она нужна по сценарию.
- Функциональное и нагрузочное тестирование.
Результат этапа
Работающая сборка на тестовом окружении, подключённая к копии учётной системы, и исходный код в репозитории заказчика. Серверную часть таких систем мы пишем на Python — стек описан на страницах разработки на Django и на FastAPI, состав проверок — на странице тестирования и QA.
Проверьте перед следующим этапом
- Все сценарии первой версии проходят на тестовом окружении?
- Обмен с учётной системой проверен на реальном объёме данных?
- Права ролей проверены: сотрудник не видит лишнего?
Типичная ошибка на этом этапе
Тестировать на выдуманных данных. Справочник из двадцати товаров работает быстро, а рабочий каталог на десятки тысяч позиций с дублями и пустыми полями находит ошибки только на пилоте.
Этап 5. Пилот в одном подразделении
Что происходит: новое рабочее место получает одна смена, один склад или одна группа операторов, остальные работают по-старому — это даёт сравнение на одинаковых условиях. Команда ежедневно собирает замечания и выпускает исправления прямо во время пилота.
Что входит в этап
- Обучение пилотной группы и назначение ключевого пользователя.
- Работа в АРМ на реальных операциях.
- Повторные замеры тех же операций, что на обследовании.
- Решение: тиражировать, доработать или изменить подход.
Результат этапа
Отчёт пилота: замеры «до и после», список правок и решение о тиражировании. Это первая точка, где эффект АРМ виден в цифрах.
Проверьте перед следующим этапом
- Время частых операций сравнено с замерами первого этапа?
- Критичные замечания пилотной группы закрыты?
- Готов план переноса данных и график обучения остальных?
Типичная ошибка на этом этапе
Отдать пилот команде, которая и так опережает остальных по скорости. Опытные сотрудники справятся с любым интерфейсом, и замеры покажут эффект, которого не будет у новичков. Для пилота подходит подразделение со средним опытом и обычной нагрузкой.
Этап 6. Тиражирование, обучение и перенос данных
Что происходит: рабочее место получают остальные подразделения — волнами, а не всей компанией в один день. Параллельно переносят данные из старых таблиц и обучают сотрудников; ключевые пользователи из пилота помогают коллегам в первые недели.
Что входит в этап
- График подключения подразделений волнами.
- Перенос и сверка данных из старых таблиц и систем.
- Короткие инструкции под каждую операцию, видео, ответы на частые вопросы.
- Передача доступов, документации и регламента поддержки.
Результат этапа
АРМ работает у всех сотрудников роли, старые таблицы закрыты на запись, у компании есть техническая документация и инструкции. Для инструкций хорошо работает корпоративная база знаний.
Проверьте перед запуском
- Каждое подразделение знает дату своего подключения?
- Данные после переноса сверены с источником?
- Сотрудники знают, куда обращаться с вопросами в первую неделю?
Типичная ошибка на этом этапе
Оставить старый путь «на всякий случай». Пока можно работать и в АРМ, и в таблице, половина сотрудников остаётся в таблице, данные расходятся, а замеры эффекта теряют смысл.
Поддержка и развитие после запуска
После запуска поведение АРМ зависит от систем вокруг: обновилась учётная система — меняется формат обмена, появился новый склад — нужны новые справочники. Поэтому поддержка — это регулярные работы: наблюдение за ошибками и обменом данными, обновления безопасности и операционных систем, помощь пользователям.
Развитие добавляет новые роли и функции, и его удобно оплачивать по фактически затраченным часам с оценкой перед каждой задачей. Если АРМ делал другой подрядчик, сопровождение начинают с аудита кода и передают на техническую поддержку. Годовой бюджет — в статье о стоимости поддержки после запуска.
Сколько стоит внедрение АРМ
Единой цены у АРМ нет: рабочее место оператора с двумя интеграциями и складской АРМ с работой без связи различаются по объёму в разы. Смета заказной разработки считается по часам и ролям команды — аналитик, дизайнер, разработчики, инженер по тестированию, менеджер проекта.
Семь факторов, которые определяют бюджет
| Фактор | Что увеличивает объём работ | Как сократить без потери смысла |
|---|---|---|
| Число ролей | Каждая роль — свои экраны, права и сценарии | Первая версия для одной-двух ролей |
| Интеграции | Каждая система, особенно без готовых методов обмена | Подключать только системы, без которых роль не работает |
| Состояние учётной системы | Дубли в справочниках, доработки без документации | Навести порядок в справочниках до разработки |
| Работа без связи | Локальное хранение и синхронизация данных | Работа без связи только для операций, где связь пропадает на практике |
| Число устройств и платформ | Компьютер, веб, планшет, терминал сбора данных | Одна кодовая база под все устройства |
| Требования к защите данных | Шифрование, журналы, размещение на серверах компании | Согласовать требования на этапе ТЗ, а не перед запуском |
| Перенос данных | Старые таблицы и системы с разной структурой | Переносить только данные, нужные для работы |
Модели оплаты и ставки
Фиксированная цена подходит, когда техническое задание утверждено и объём понятен. Оплата по фактически затраченным часам (Time & Materials) — когда процесс уточняется по ходу, как часто бывает с АРМ после пилота. Разница моделей — в статье Fixed Price или Time & Materials, структура сметы — в материале о стоимости разработки ПО.
Ставки FITTIN по Time & Materials опубликованы на странице тарифов: от 2 625 до 4 200 ₽ в час с НДС в зависимости от роли специалиста. Мы федеральная команда с центром разработки в Воронеже: распределённая модель позволяет держать эффективные ставки без потери качества. Точная сумма появляется после технического задания, оценку по часам и ролям даёт команда разработки ПО на заказ.
В смету разработки обычно не входят лицензии учётных систем и доработки на их стороне, оборудование (терминалы, сканеры, принтеры этикеток), серверы или облако и время собственных сотрудников на обследовании, пилоте и обучении.
Если задача — канал продаж, а не внутреннее рабочее место
Иногда за запросом «автоматизировать работу менеджеров» стоит другая задача — перевести заказы клиентов в приложение и сайт. Для этого есть модульная Flutter-платформа FITTIN: приложение и сайт собираются из готовых модулей с интеграциями с 1С и маркетплейсами. Модель оплаты из трёх частей: единоразовая интеграция под бренд до 30 рабочих дней (приложение на тарифе ПРО — от 525 000 ₽); ежемесячная лицензия от 150 000 ₽, в которую включены затраты на техническую поддержку команды FITTIN, поэтому собственная команда для базового сопровождения не требуется; новый функционал и доработки — отдельно по Time & Materials. Платформа внесена в реестр российского ПО Минцифры (№ 2487103), подробнее — на странице мобильных приложений для e-commerce.

Как измерить эффект от АРМ
Эффект считают по тем же операциям, что замеряли на обследовании. Без замера «до» любое улучшение остаётся ощущением.
| Показатель | Как замерить до внедрения | Откуда брать после |
|---|---|---|
| Время типовой операции | Хронометраж пяти–десяти операций на обследовании | Журнал действий АРМ: начало и конец операции |
| Доля ошибок | Возвраты, пересорт, повторные доставки за квартал | Те же отчёты учётной системы за сопоставимый период |
| Ручные переносы данных | Число копирований между системами на одну операцию | Схема обмена: какие переносы стали автоматическими |
| Операций на сотрудника в смену | Учётная система или ручной подсчёт по сменам | Статистика АРМ по пользователям |
| Срок выхода новичка на норму | Опрос руководителей: сколько смен до самостоятельной работы | Статистика новых пользователей АРМ |
| Обращения в ИТ-службу | Заявки по теме роли за месяц | Те же заявки после тиражирования |
В деньги эффект переводят через стоимость времени и ошибок: сэкономленные минуты умножают на число операций и стоимость часа сотрудника, сокращение возвратов — на стоимость одной ошибки. Подробнее — в статье о пятнадцати метриках разработки.

Как выбрать подрядчика
АРМ — проект про процесс, а не только про код. Шесть вопросов до договора:
- Кто будет обследовать процесс? Нужен аналитик, который проведёт время рядом с сотрудниками, а не только соберёт требования на встрече.
- Был ли опыт интеграций с вашими системами? Как подрядчик подключался к 1С, складу или CRM и что делал, когда методов обмена не хватало.
- Предусмотрен ли пилот? Пилот с замерами должен быть этапом плана.
- Где будут код и доступы? Репозиторий, серверы и учётные записи оформляются на компанию с первого дня.
- Как устроена поддержка? Время реакции, состав регламента, оценка новых функций.
- Как считается смета? Часы по ролям и этапам, а не одна сумма без расшифровки.
Роли в команде разобраны в статье о составе команды разработки, сравнение подряда с наймом — в материале о подряде и собственной команде. Если своя ИТ-служба уже есть, отдельных специалистов подключают через аутстаффинг бэкенд-разработчиков. Что зафиксировать до старта — в чек-листе по бюджету и срокам.
Кейсы: рабочие места сотрудников в проектах
В проектах FITTIN рабочие места сотрудников появляются как часть системы продаж. Цифры приведены со страниц кейсов.
Marc O'Polo — релиз за 4 месяца и собственная админ-панель
Приложение fashion-бренда прошло путь от старта до релиза за 4 месяца, пять команд работали в едином недельном ритме. Отдельной задачей стало рабочее место команды бренда: контент карточек, баннеры и подборки сотрудники меняют сами в собственной админ-панели — без кода и без очереди к разработчикам.
One Price Coffee — сеть из 350+ кофеен с кешбэком от 3 до 10%
Для федеральной сети кофеен по франшизе с программой лояльности на 4 уровня с кешбэком от 3 до 10% важной частью проекта стала работа управляющей компании. Перед запуском она получает отчёт о готовности каждой точки: реквизиты, лояльность, смены, терминалы. Стоп-листы обновляются каждые 15 минут по всей сети.
«Сатурн» — конверсия в покупку 12,4%
Сеть строительных гипермаркетов в 20+ городах с каталогом свыше 30 000 товаров. Приложение связано с 1С и региональными складами, заказ можно оформить на физлицо или юрлицо. По данным страницы кейса — 7 594 установки за первый месяц и конверсия в покупку 12,4%.
Остальные проекты — в разделе кейсов. Внутренние приложения для сотрудников описаны на странице корпоративных приложений, рабочие места для продаж юрлицам — на странице B2B-приложений.

Итог: АРМ на одной странице
Автоматизированное рабочее место — это экраны, данные и действия, собранные под одну роль и связанные с системами компании. Порядок действий:
- Начните с обследования — замеры операций дают и список задач, и базу для оценки эффекта.
- Выберите путь под роль — типовая конфигурация, доработка системы, заказная разработка или конструктор.
- Ограничьте первую версию — одна-две роли и только нужные интеграции.
- Проведите пилот с замерами — одно подразделение, сравнение «до и после».
- Тиражируйте волнами и закройте старые пути.
- Заложите поддержку и развитие — АРМ живёт вместе с системами вокруг него.
Что делать дальше:
- Описать процесс и требования — бизнес-аналитика и разработка технического задания.
- Оценить разработку по часам и ролям — разработка ПО на заказ, ставки — на странице тарифов.
- Проверить действующую систему или передать её на сопровождение — аудит кода и техническая поддержка.
Вопросы и ответы
Чем АРМ отличается от CRM или ERP-системы?
CRM и ERP хранят данные и правила всей компании: клиентов, заказы, склад, финансы. АРМ — рабочий интерфейс конкретной роли, который берёт данные из одной или нескольких таких систем и показывает их в порядке, удобном для операции.
Сколько времени занимает внедрение АРМ?
При заказной разработке шесть этапов — от обследования до тиражирования — складываются в 85–225 рабочих дней, примерно 4–11 месяцев, а первая версия на пилоте появляется через 65–175 рабочих дней. Настройка типовой конфигурации учётной системы занимает 10–40 рабочих дней. Срок определяют число ролей, интеграции и скорость, с которой компания даёт доступы и тестовые данные.
Сколько стоит разработка АРМ?
Смета считается по часам и ролям команды после технического задания, поэтому одной цены нет. На бюджет влияют число ролей, интеграции, состояние учётной системы, работа без связи, число устройств, защита данных и перенос данных. Ставки FITTIN по Time & Materials — от 2 625 до 4 200 ₽ в час с НДС. Лицензии учётных систем и оборудование считаются отдельно.
Можно ли сделать АРМ на базе 1С, без отдельной разработки?
Да, если роль работает в основном в 1С и процесс близок к типовому: бухгалтерия, кадры, склад со стандартными операциями. Отдельное приложение имеет смысл, когда роль использует несколько систем сразу, работает на терминале или планшете, нуждается в работе без связи или когда доработки конфигурации трудно обновлять. 1С при этом остаётся главной системой для данных.
Нужно ли техническое задание для АРМ и кто его пишет?
Нужно: по нему считают смету, подписывают договор и принимают работу. Пишет его аналитик по итогам обследования, согласуют владелец процесса, ИТ-служба и служба безопасности. В ТЗ входят сценарии операций, ролевая модель, интеграции, требования к работе без связи и защите данных, состав первой версии. Его можно заказать отдельно и передать любому подрядчику.
Как учесть требования к защите персональных данных в АРМ?
Если в рабочем месте есть данные клиентов или сотрудников, их обработку регулирует закон № 152-ФЗ «О персональных данных». На практике это ролевая модель доступа, журнал действий, защищённое соединение, резервное копирование и выбор места хранения. Конкретные меры определяют служба безопасности и юрист на этапе требований — так они попадают в ТЗ и смету.
Можно ли сделать АРМ для планшета или терминала сбора данных без интернета?
Можно. Для склада, торгового зала и выездных сотрудников АРМ хранит нужные данные на устройстве и отправляет изменения, когда связь появляется. Такой режим увеличивает объём работ, поэтому его включают только для операций, где связь пропадает на практике.
Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.