С чего начать корпоративное веб-приложение? С одного процесса, который сегодня ведётся в таблицах и переписке и от которого страдают конкретные люди. Затем записываются роли (кто что видит и делает), источники данных и способ входа. Только после этого определяется первая версия и пилотная группа, на которой приложение проверяют до запуска для всех.
Такой порядок нужен потому, что корпоративное приложение отличается от сайта не интерфейсом, а средой: вход через каталог компании, права по подразделениям, журнал действий, размещение внутри контура, обмен с 1С. Эти требования выясняются заранее, иначе всплывают на приёмке. Услуга описана на странице «Разработка корпоративных веб-приложений», здесь только порядок первых шагов.
Шаг 1. Выберите один процесс
Самая частая ошибка начала: взять «все внутренние процессы» и пытаться сделать единую систему. Она не запускается никогда, потому что у каждого подразделения свои правила, а общего владельца нет. Берите один процесс и проверьте его по критериям:
| Критерий | Хороший признак | Плохой признак | Вопрос владельцу |
|---|---|---|---|
| Боль | Заявки теряются, сроки срываются, статус неизвестен, а люди тратят время на переписку | «Хочется порядка» без конкретных потерь | Что случилось за последний месяц из-за того, что процесс ведётся так |
| Владелец | Есть человек, который отвечает за результат процесса и готов решать спорные вопросы | Процесс «общий», решения откладываются на совещание | Кто скажет, как правильно, если два подразделения не согласны |
| Повторяемость | Процесс повторяется каждый день или неделю, маршрут в целом одинаков | Каждый случай особенный и решается руководителем | Сколько таких случаев в неделю и сколько из них типовых |
| Участники | Круг людей известен и ограничен: одно-два подразделения для пилота | Участвует вся компания, и неизвестно, кто именно | Назовите людей, которые будут работать в приложении в первую неделю |
| Данные | Понятно, откуда они берутся: из учёта, из справочника или вводятся впервые | Данные разбросаны по файлам, и нет человека, который знает, какой из них правильный | Где лежит эталонный справочник, который можно взять за основу |
Если по двум критериям из пяти ответ плохой, процесс лучше сначала упорядочить организационно. Приложение закрепит порядок, но не создаст его: автоматизация беспорядка даёт быстрый беспорядок.
Шаг 2. Опишите людей и права
Приложение обслуживает не «пользователей вообще», а конкретные роли. Для каждой записывается, что человек видит, что делает и как у него отзывается доступ. Это короткая таблица, но она определяет объём работы сильнее, чем число экранов.
| Роль | Что видит | Что может делать | Что не должна |
|---|---|---|---|
| Инициатор | Свои заявки и их статусы | Создать заявку, добавить вложение, отозвать до согласования | Видеть заявки коллег и менять заявку после согласования |
| Согласующий | Заявки своего подразделения, ждущие решения | Согласовать, вернуть с комментарием, передать заместителю | Согласовывать собственные заявки |
| Исполнитель | Очередь принятых к исполнению заявок | Взять в работу, изменить статус, приложить результат | Менять маршрут и состав согласующих |
| Администратор приложения | Справочники, права, журнал | Добавить подразделение, назначить замещающего, выгрузить журнал | Менять содержимое заявок в обход журнала |
Вокруг таблицы решаются четыре вопроса, которые чаще всего забывают.
- Замещение. Согласующий в отпуске, и заявка висит. Замещение настраивается в приложении по датам, а решения замещающего подписаны его именем.
- Отзыв доступа. Права привязаны к должности и подразделению, а не выданы навсегда. Когда человек переходит в другой отдел или увольняется, доступ меняется сам, а не по заявке в ИТ.
- Исключения. Если маршрут в реальности регулярно ломается одним и тем же способом, это записывается как правило, а не ловится руками администратора.
- Проверка на сервере. Права проверяются на каждый запрос к серверу, а не скрытием кнопок. Скрытая кнопка не запрещает действие, если запрос можно отправить напрямую.
Шаг 3. Решите, откуда данные и как входит сотрудник
Здесь принимаются два решения, которые труднее всего менять потом.
Откуда берутся данные
Для каждого поля записывается источник и хозяин. Номенклатура, контрагенты и остатки обычно остаются в 1С и приходят в приложение копией. Оргструктура и состав подразделений берутся из каталога. Статус заявки, комментарии и решения ведёт само приложение. Если поле можно править в двух местах, оно рано или поздно разойдётся, и пользователи перестанут верить обоим источникам. Способы обмена с 1С разобраны в статье «Проектирование API для интеграций», а общая картина обмена — на странице интеграции 1С.
Как сотрудник входит
| Вариант | Когда подходит | Что платите | На что смотреть |
|---|---|---|---|
| Вход через каталог (Active Directory, LDAP) | В компании уже есть каталог, а приложение стоит внутри сети | Подключение к каталогу и сопоставление групп с ролями | Что будет, если каталог недоступен, и кто управляет группами |
| Единый вход (SSO) | Несколько приложений, нужна общая точка входа и политика паролей | Развёртывание и поддержка сервера входа или подключение к существующему | Один отказ сервера входа останавливает все приложения |
| Свои учётные записи | Каталога нет или приложением пользуются внешние люди | Хранение паролей, восстановление доступа, двухфакторный вход | Отзыв доступа остаётся ручным: его нужно регламентировать |
Если каталога нет или он меняется, смотрите страницы «SSO и MFA для корпоративных систем» и «Замена Active Directory на Linux». Сравнение подходов к входу — в статье «SSO и MFA: что выбрать».
Шаг 4. Выберите, где будет жить приложение
Размещение влияет на цену и сроки больше, чем кажется. Вопросы, на которые нужен ответ до разработки:
- Где работает. На вашем сервере, у выбранного вами хостера или в облаке, которое одобрила служба безопасности. Если данные относятся к ограниченному доступу, внешние облачные сервисы часто не подходят по требованиям заказчика. Персональные данные граждан России обычно должны храниться на серверах в России. Общее сравнение вариантов — в статье «On-premise или облако».
- Нужен ли доступ извне. Работа только из корпоративной сети проще и безопаснее, а доступ из дома или с выезда добавляет защищённое подключение и требования к устройствам.
- Кто ставит обновления. Серверу нужны обновления системы и зависимостей. Если за него отвечает ваш ИТ-отдел, договоритесь об окне. Если никто, это надо поручить подрядчику в сопровождении.
- Копии и восстановление. Копия, из которой ни разу не восстанавливались, не считается. Проверку восстановления записывают в регламент.
- Тестовый стенд. Должен повторять боевой, иначе выкладка превращается в эксперимент на живых пользователях.
Если в приложении будут персональные данные сотрудников, юридические вопросы (согласия, статус оператора, документы) решает юрист заказчика. Мы даём технические меры: шифрование, права, журнал.
Шаг 5. Определите первую версию и что откладывается
Первая версия закрывает один маршрут от начала до конца на реальных данных. Всё, без чего этот маршрут работает, откладывается. Работает правило: если пилотная группа может обойтись без функции, её нет в первой версии.
| Часть приложения | Входит в первую версию | Откладываем | Когда возвращаемся |
|---|---|---|---|
| Заявки | Один тип заявки, поля, вложения, статусы | Конструктор типов заявок, настраиваемые поля | Появился второй процесс с похожим маршрутом |
| Маршрут | Фиксированный маршрут по подразделениям, замещение по датам | Сложные условия («если сумма больше порога и категория X») | Исключения повторяются и их можно описать правилом |
| Уведомления | Письмо о новой задаче и о просрочке | Мессенджеры, настройки уведомлений по пользователям | Сотрудники жалуются, что не видят задачи |
| Отчёты | Список заявок с фильтрами и выгрузка в файл | Панели показателей, сводные отчёты из нескольких систем | Руководитель регулярно собирает отчёт руками |
| Интеграции | Справочники из учёта копией, вход через каталог | Запись результата обратно в 1С, обмен с документооборотом | Ручной перенос результата стал занимать заметное время |
| Права | Три-четыре роли, подразделения из каталога | Права на уровне отдельных полей и документов | Появилась задача, где часть данных нельзя показывать части участников |
Оба списка подписываются до начала разработки. Новая функция оценивается отдельно, а не добавляется молча: так работает приёмка, и так сохраняется бюджет. Подробнее про ограничение объёма — в статье «Как составить техническое задание на разработку».
Шаг 6. Запустите пилотную группу и назначьте дату отказа от старого
Приложение проверяется людьми, а не тестами. Поэтому до запуска для всех оно работает у одной группы: одно подразделение или одна смена.
- Критерии приёмки пишутся заранее. Заявка проходит весь маршрут; из-под каждой роли недоступно чужое; доступ закрывается при отключении учётной записи; выгрузка совпадает с учётом на выборке.
- Обучение короткое. Двадцать минут и страница инструкции для каждой роли. Если приложение нельзя объяснить за двадцать минут, интерфейс надо упрощать, а не обучение удлинять.
- Журнал читается каждую неделю. Где пользователи останавливаются, какие поля оставляют пустыми, какие действия повторяют. Это дешевле интервью и точнее.
- Старый способ отключается по дате. Пока рядом живут таблица и почта, часть людей продолжит ими пользоваться. Дату согласует руководитель подразделения, а если параллельная работа неизбежна, определите, какая система главная.
- Правки до расширения. Остальные подразделения подключаются после исправлений по итогам пилота, а не вместе с ними.
Признак того, что пилот удался, — группа продолжает пользоваться приложением, когда никто не напоминает. Если без напоминаний возвращаются к таблице, причина почти всегда в лишних шагах или в том, что старый способ остался удобнее.
Типичные ошибки при старте
Ошибки повторяются от проекта к проекту, поэтому их стоит проверить до заказа.
| Ошибка | К чему приводит | Как избежать |
|---|---|---|
| Начали с интерфейса | Экраны утверждены, а выяснилось, что нужные данные недоступны или права устроены иначе | Сначала роли и источники данных, потом макеты интерфейса |
| Описали процесс «как должно быть» | Приложение не совпадает с реальной работой, и люди обходят его | Записать процесс «как есть» со слов исполнителей, а не из приказа |
| Согласовали только с руководителем | Пользователи узнали о приложении в день запуска | Показать макеты интерфейса тем, кто будет работать, до разработки |
| Пытаются заменить всё сразу | Бюджет и сроки растут, запуск откладывается | Один маршрут, одна группа, расширение после пилота |
| Не назначили владельца | Приложение развивается рывками или не развивается совсем | Один человек со стороны заказчика принимает решения и отвечает за результат |
| Забыли про сопровождение | После запуска сервер не обновляется, копии не проверяются, обращения идут к автору | Заранее решить, кто отвечает за мониторинг, обновления и обращения |
Когда своё приложение не нужно
Иногда дешевле не писать приложение. Три случая:
- Процесс типовой. Учёт клиентов, обращения, документооборот: существует много готовых систем. Если компания готова подстроиться под них, начните с готового решения. Как сравнивать по стоимости владения, описано в статье «Коробочное ПО или заказная разработка».
- Участников мало, процесс простой. Если заявок несколько в неделю и ими занимается один человек, таблица с общим доступом и правилами обойдётся дешевле.
- Процесс не договорён. Если подразделения не согласны, как работать, приложение только закрепит спор. Сначала решение владельца, потом разработка.
Если приложение нужно клиентам или партнёрам, а не сотрудникам, это другая задача: личный кабинет или B2B-портал. Если речь об учёте объектов и договоров, см. CRM на заказ.
Что делаем мы и с чего начать
Начинаем с обследования: 200 000 ₽ и 2–3 недели за одно приложение и одну-две системы, 350 000 ₽ и 3–4 недели, если приложение связано с несколькими системами. На выходе маршрут процесса «как есть», таблица ролей, таблица источников данных, решение о входе и размещении, список «входит в первую версию / откладываем» и вилка бюджета. Стоимость вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться и без нас.
Дальше, если нужно, лёгкий пилот (150 000–400 000 ₽, 2–8 недель) или тяжёлый (400 000–1 200 000 ₽, 2–3 месяца), затем вывод в эксплуатацию от 1 500 000 ₽ этапами по 300 000–700 000 ₽, и на любой ступени можно остановиться. Мы делаем одно приложение вокруг одного процесса, а не внедряем систему целиком, не делаем мобильные приложения и не дежурим круглосуточно. Исходники лежат в вашем репозитории с первого коммита. Все цены и сроки — на странице «Тарифы», описание услуги — на странице «Разработка корпоративных веб-приложений».
Частые вопросы
С чего начать разработку корпоративного веб-приложения?
С выбора одного процесса, у которого есть конкретная боль и владелец, и с описания ролей: кто что видит и делает. Затем решаются вопросы данных, входа и размещения, и только после этого определяется первая версия. Макеты интерфейса и технологии идут последними.
Сколько стоит разработка корпоративного приложения?
Точная цена называется после обследования: 200 000 ₽ за одно приложение и одну-две системы, 350 000 ₽ при нескольких системах. Простое приложение укладывается в лёгкий пилот (150 000–400 000 ₽), с ролями и интеграциями — в тяжёлый (400 000–1 200 000 ₽). Вывод в эксплуатацию начинается от 1 500 000 ₽.
Сколько времени занимает запуск?
Обследование занимает 2–3 недели, разработка простого приложения — от четырёх недель, затем проверка и пилотная группа. Сроки растут вместе с числом ролей, систем и требований к входу и размещению. Точные сроки называем по итогам обследования.
Нужно ли подключать приложение к Active Directory?
Если в компании есть каталог, лучше подключить: сотрудник не заводит ещё один пароль, а доступ закрывается вместе с учётной записью. Если каталога нет или приложением пользуются внешние люди, используются свои учётные записи с двухфакторным входом.
Можно ли начать с готового решения?
Можно, и для типовых процессов это часто разумно. Заказное приложение оправдано, когда процесс отличает вас от остальных, а готовая система потребует переделки или заставит вести данные в двух местах. Сравнивать нужно стоимость владения, а не цену лицензии.
Как не допустить, чтобы приложением не пользовались?
Показать макеты интерфейса тем, кто будет работать, до разработки; запустить пилотную группу; читать журнал действий; назначить дату отказа от старого способа и владельца процесса со стороны заказчика. Чаще всего приложением не пользуются из-за лишних шагов.
Где хранятся данные и кому принадлежит код?
На ваших серверах или у выбранного вами хостера. Исходный код лежит в вашем репозитории с первого коммита, результат работ передаётся по акту, порядок передачи прав записывается в договоре, открытые компоненты остаются под своими лицензиями.
Делаете ли вы мобильное приложение для сотрудников?
Нативные приложения для iOS и Android не делаем. Интерфейс адаптивный и открывается на телефоне в браузере; если нужна установка на экран, это возможно как адаптивное веб-приложение. Нативное приложение оценивается отдельно, а мы подскажем, когда оно действительно нужно.