Когда обычного сайта уже недостаточно
Корпоративный сайт или веб-система объединяет внешние и внутренние бизнес-процессы компании в одном онлайн-пространстве. В проект могут входить каталоги, внутренние сервисы и личные кабинеты сотрудников, а также кабинеты для B2B- и B2C-клиентов с системой документооборота.
Каталоги, документы, услуги, филиалы и другие сведения хранятся в одной системе. Ответственные сотрудники обновляют информацию в предназначенных для них разделах, а клиентам и подразделениям не приходится работать с разными версиями одних и тех же данных.
Клиенты и партнеры получают доступ к своим заказам, документам, счетам, обращениям и статусам их обработки. Доступные данные и действия определяются условиями работы и категорией пользователя.
Подразделения работают с заявками, документами, каталогами и внутренними операциями через предназначенные для них интерфейсы. Сотрудники видят необходимые данные и выполняют действия в соответствии со своими обязанностями.
Для сотрудников, руководителей, администраторов, партнеров и клиентов настраиваются отдельные права. Каждый пользователь видит только разрешенные ему разделы, документы, данные и операции.
Корпоративная веб-система может получать и передавать данные в CRM, ERP, складские, учетные и другие сервисы. Сотрудникам не приходится повторно переносить сведения о клиентах, товарах, заказах и документах из одной системы в другую.
После запуска заказчику передаются исходный код, административные и серверные доступы, ключи подключенных сервисов и техническая документация. Компания может продолжить работу со мной, передать поддержку другому специалисту или развивать систему собственной командой.
Выбор формата
Такой проект нужен, когда сайт должен не только представлять компанию, но и предоставлять клиентам, партнерам и сотрудникам доступ к данным, документам и рабочим операциям.
Необходимость корпоративной разработки определяется не размером компании, а задачами, которые должны выполняться через сайт. Небольшому B2B-поставщику может потребоваться сложный кабинет для партнеров, а крупной компании иногда достаточно обычного информационного сайта.
Корпоративный сайт или веб-система необходимы, если:
Если сайт должен только рассказать о компании, представить ее услуги и проекты и принять обращение, сложная корпоративная система не требуется. Для такой задачи достаточно многостраничного бизнес-сайта.
Корпоративный сайт подходит компании, которой необходимо представить большое количество направлений, подразделений и материалов. На нем могут размещаться отдельные разделы для филиалов и регионов, каталоги товаров и услуг, выполненные проекты, документы, новости, экспертные материалы и информация для партнеров.
Управление такой структурой распределяется между ответственными сотрудниками. Одно подразделение обновляет каталог, другое публикует документы, третье отвечает за новости или страницы филиалов. Для каждого сотрудника определяется, какие разделы он может просматривать, редактировать и публиковать.
Корпоративный сайт может включать:
Веб-система необходима, когда авторизованные пользователи должны не только получать информацию, но и выполнять действия. Клиент может загрузить документ, проверить состояние заказа или получить счет. Партнер — работать с доступным ему каталогом и условиями. Сотрудник — обрабатывать заявку, согласовывать документ или изменять статус операции.
В состав веб-системы могут входить:
Корпоративный сайт и веб-система могут быть объединены в одном проекте. Публичная часть представляет компанию и ее предложения, а закрытая используется клиентами, партнерами и сотрудниками для работы с доступными им данными, документами и операциями.
Если компании необходимо представить несколько товаров или услуг, рассказать об опыте, опубликовать проекты, контакты и условия работы, эту задачу решает бизнес-сайт. Если продвигается одно предложение для конкретной рекламной кампании, достаточно посадочной страницы.
Корпоративная разработка оправдана только тогда, когда проекту действительно нужны сложная структура, разные категории пользователей, личные кабинеты, права доступа, документооборот или интеграции с внутренними системами. Функции не добавляются только для того, чтобы искусственно увеличить объем и стоимость проекта.
После запуска системы
Клиенты получают доступ к предназначенным для них данным и документам, сотрудники работают с обращениями в собственных интерфейсах, а информация передается между подключенными системами по установленным правилам.
В личном кабинете клиент может самостоятельно получить доступные ему документы, счета, заказы, обращения и их текущие статусы. Сотрудникам не приходится повторно отправлять информацию, которая уже находится в системе.
Сведения о клиентах, товарах, заказах и документах передаются между сайтом, CRM, ERP и другими подключенными системами. Сотрудникам не приходится вручную копировать одну и ту же информацию из одного сервиса в другой.
Заявка может направляться ответственному сотруднику с учетом выбранной услуги, региона, категории клиента или другого установленного условия. Вместе с контактами передается информация о причине обращения и выполненных пользователем действиях.
Для заявки, заказа или документа фиксируются ответственный сотрудник, текущий статус и история изменений. Руководитель и участники процесса могут увидеть, на каком этапе находится работа и какие действия уже были выполнены.
При изменении статуса система может уведомить сотрудника, клиента или партнера, передать документ следующему участнику и открыть предусмотренное действие. Автоматически выполняются только заранее согласованные операции.
Для сотрудников, клиентов, партнеров и филиалов создаются предусмотренные категории доступа. Новому пользователю назначается соответствующая роль, после чего он получает доступ только к необходимым ему данным и функциям.
Как создается корпоративная система
Корпоративный проект нельзя начинать с дизайна отдельных страниц. Сначала необходимо определить процессы, пользователей, данные, права доступа и правила обмена с другими системами. Работа делится на восемь этапов, результаты которых последовательно проверяются и согласовываются с заказчиком.
До заключения договора на полную разработку определяется, какие задачи должна решать система и кто будет ей пользоваться. Изучаются существующие сайты, CRM, ERP, каталоги, документы и другие источники информации, с которыми потребуется работать.
На этом этапе также определяется, действительно ли компании нужна корпоративная веб-система или поставленную задачу можно решить более простым способом.
Результат этапа: согласованные цели и границы проекта, перечень основных функций, предварительные сроки и ориентировочная стоимость разработки.
Для каждого процесса определяется, где он начинается, кто в нем участвует, какие действия выполняются и какой результат должен быть получен. Описываются категории пользователей, права доступа, структура данных и системы, из которых поступает информация.
Для интеграций фиксируется, какие данные передаются, в каком направлении выполняется обмен, какая система является основной и что должно происходить при ошибке.
Результат этапа: техническое задание, структура данных, схема ролей и прав доступа, перечень интеграций и критерии приемки системы.
Создаются прототипы публичных страниц, личных кабинетов и рабочих экранов сотрудников. Для каждой категории пользователей проверяется, какая информация для них доступна, какие действия может выполнить и какой результат получает после выполнения операции.
После согласования прототипов разрабатывается дизайн для компьютеров, ноутбуков, планшетов, смартфонов и промежуточных размеров экрана.
Результат этапа: утвержденные прототипы и дизайн основных страниц, кабинетов и рабочих интерфейсов.
Собираются и распределяются по разделам тексты, изображения, документы, каталоги, справочники и другие материалы. Для переноса данных определяются источники, сопоставляются поля, удаляются выявленные дубли и подготавливаются правила импорта.
Достоверность исходной информации проверяется ответственными сотрудниками заказчика. Перед основным переносом выполняется тестовый импорт и проверяется полученный результат.
Результат этапа: подготовленные материалы, согласованные правила переноса и проверенный набор данных для загрузки в систему.
Последовательно создаются публичная часть, административная система, личные кабинеты, каталоги, документы, поиск, роли пользователей и другие предусмотренные проектом функции. Модули размещаются на тестовом сервере по мере готовности.
Заказчик получает промежуточные рабочие версии и проверяет их до перехода к следующей части проекта. Выявленные отклонения от согласованных требований устраняются в процессе разработки.
Результат этапа: рабочие модули корпоративного сайта или веб-системы на тестовом сервере.
Система подключается к CRM, ERP, учетным, складским и другим сервисам, включенным в состав проекта. Проверяется передача данных в обоих направлениях, обработка ошибок, повтор неудачных операций и фиксация результатов обмена.
После проверки интеграций выполняется перенос согласованных каталогов, документов, пользователей и другой информации из существующих систем.
Результат этапа: работающий обмен данными с подключенными сервисами и перенесенная в новую систему информация.
Проверяются права доступа, пользовательские операции, формы, документы, поиск, импорт данных и работа интеграций. Отдельно тестируются обработка ошибок и отображение интерфейсов на предусмотренных устройствах.
Проверка производительности, резервного копирования, восстановления и работы под нагрузкой проводится в том случае, если соответствующие требования входят в состав проекта. Заказчик выполняет приемочные испытания по заранее согласованным сценариям.
Результат этапа: проверенная и принятая заказчиком версия системы, готовая к размещению в рабочей среде.
Проект размещается на рабочем сервере, подключаются домен и защищенное соединение, настраиваются журналы ошибок, резервное копирование и мониторинг, если они предусмотрены составом работ. После запуска повторно проверяются права доступа, формы, интеграции и передача реальных данных.
Для критичных процессов система может сначала запускаться для ограниченной группы пользователей. После проверки сотрудники заказчика получают инструкции и обучение по работе с предусмотренными для них функциями.
Заказчику передаются исходный код, административные и серверные доступы, ключи подключенных сервисов, инструкции по развертыванию и техническая документация. Дальнейшая поддержка и развитие системы заказываются отдельно.
Результат этапа: запущенная корпоративная система, полностью переданная под контроль компании.
Принципы ценообразования
Минимальная стоимость корпоративного проекта составляет 250 000 ₽. До начала основной разработки проводится обследование, после которого фиксируются состав системы, стоимость этапов и результаты, которые должен получить заказчик.
Работа рассчитывается по ставке 3 700 ₽ за час. Большинство корпоративных сайтов и веб-систем с ограниченным набором личных кабинетов и интеграций находится в диапазоне от 250 000 до 650 000 ₽.
Сложные веб-системы с несколькими категориями пользователей, документооборотом, переносом большого объема данных и несколькими интеграциями оцениваются отдельно. Стоимость таких проектов может превышать 650 000 ₽.
Если проекту не требуются личные кабинеты, интеграции, перенос данных или дополнительные функциональные модули, эти работы не включаются в смету. Оплата производится поэтапно. До начала каждого этапа заказчик знает его состав, стоимость и ожидаемый результат.
Серверная инфраструктура, домен, лицензии, CRM и ERP, телефония, SMS- и email-сервисы, платные API, облачные хранилища, рекламный бюджет и услуги сторонних специалистов не входят в стоимость разработки и при необходимости оплачиваются отдельно.
| Этап | Объем работ | Кол-во часов |
|---|---|---|
| Предварительное обследование и границы проекта | Определение задач системы, процессов, которые войдут в проект, категорий пользователей, существующих сервисов и ожидаемых результатов. Подготовка предварительного состава работ и критериев приемки | 8–12 ч. |
| Архитектура данных, ролей и интеграций | Проектирование структуры данных, ролей и прав доступа. Определение источников информации, правил обмена между системами, обработки ошибок и фиксации действий пользователей | 10–18 ч. |
| Прототипы и дизайн интерфейсов | Создание прототипов публичных страниц, административной части, личных кабинетов и рабочих экранов. Разработка дизайна для компьютеров, планшетов, смартфонов и промежуточных размеров экрана | 12–24 ч. |
| Подготовка материалов и данных | Структурирование текстов, изображений, документов, каталогов и справочников. Проверка источников данных, сопоставление полей и подготовка информации к публикации или импорту | 6–12 ч. |
| Разработка публичной и административной частей | Создание страниц, каталогов, поиска, фильтров, документов, административных разделов, моделей данных и других функций, предусмотренных основной частью проекта | 18–36 ч. |
| Личные кабинеты и закрытые разделы | Авторизация, восстановление доступа, профили пользователей, персональные данные, документы, доступные операции, роли и проверка прав для клиентов, партнеров или сотрудников | Опционально: 8–20 ч. |
| Интеграции и перенос данных | Подключение CRM, ERP, учетных, складских и других систем. Настройка обмена, обработка ошибок, тестовый импорт и перенос согласованных каталогов, документов, пользователей и справочников | Опционально: 8–24 ч. |
| Техническая подготовка публичной части | Настройка заголовков и описаний, Open Graph, микроразметки, sitemap.xml, robots.txt, правил индексирования, структуры URL и других технических параметров публичных страниц | 4–8 ч. |
| Тестирование и приемка | Проверка страниц, интерфейсов, прав доступа, пользовательских операций, форм, документов, поиска, импорта данных и интеграций. Проведение приемочных испытаний по согласованным сценариям | 6–12 ч. |
| Запуск, обучение и передача | Размещение системы в рабочей среде, финальная проверка, обучение сотрудников и передача исходного кода, административных и серверных доступов, ключей сервисов и технической документации | 4–8 ч. |
| Ориентировочный объем проекта | Точный объем определяется после обследования процессов, структуры данных, категорий пользователей, личных кабинетов и необходимых интеграций | 68–174 ч. |
Без мелкого шрифта
Сначала определяются границы проекта, категории пользователей, состав данных, необходимые интеграции и ответственность сторон. Это позволяет не строить корпоративную систему на предположениях и не выяснять правила ее работы после запуска.
Да. Корпоративный проект можно разделить на этапы и сначала реализовать функции, без которых система не сможет выполнять основную задачу. Например, запустить публичную часть и один тип личного кабинета, а дополнительные роли, интеграции и операции подключать по мере необходимости.
Для этого еще на этапе проектирования определяется, какие функции входят в первый запуск, а какие относятся к дальнейшему развитию. Архитектура учитывает согласованные следующие этапы, но функции не разрабатываются заранее только потому, что когда-нибудь они могут понадобиться.
Это не препятствует началу проекта, но до разработки процессы придется разобрать вместе с сотрудниками, которые участвуют в них на практике. Необходимо определить, откуда поступают данные, кто выполняет каждое действие, какие документы используются, где принимаются решения и каким результатом завершается операция.
Если правила не определены внутри компании, программирование их не создаст. Система может выполнять только понятный и согласованный процесс. Спорные ситуации и разные варианты работы должны быть разобраны до того, как они превратятся в программную логику.
В проекте должен участвовать сотрудник, который принимает решения по составу и приоритетам системы. Для разбора отдельных процессов также потребуются представители подразделений, которые работают с заказами, документами, каталогами, клиентами или другими данными.
Разработчик может спроектировать интерфейс и предложить способ реализации, но не может вместо сотрудников определить внутренние правила компании. Если решения долго не согласовываются или разные подразделения предъявляют противоречивые требования, это влияет на сроки реализации проекта.
Можно, если используемая система предоставляет техническую возможность получать и передавать необходимые данные. До начала разработки проверяются документация API, доступные методы, ограничения, формат данных, правила авторизации и допустимая частота запросов.
Также заранее определяется направление обмена: какие данные корпоративная система получает, какие передает обратно, какая система считается основной и что должно происходить при ошибке или временной недоступности интеграции.
Сначала проверяются другие официальные способы обмена: выгрузка и загрузка файлов, готовые модули, база данных, вебхуки или промежуточный сервис. Если безопасного и поддерживаемого способа интеграции нет, это ограничение фиксируется до начала соответствующего этапа.
Обходные решения, основанные на имитации действий пользователя или неофициальном доступе к закрытым частям стороннего сервиса, могут перестать работать после любого обновления. Такой риск нельзя скрывать под обещанием, что интегрировать можно что угодно.
Да, если данные доступны для выгрузки и их можно привести к структуре нового проекта. До переноса проверяются формат, объем, обязательные поля, связи между записями, дубли, устаревшие значения и качество исходной информации.
Перенос не исправляет поврежденные, противоречивые или неполные данные автоматически. Сначала определяется, что переносится без изменений, что преобразуется, что требует проверки сотрудниками заказчика, а что не должно попадать в новую систему.
Для каждой категории пользователей составляется перечень доступных разделов, данных и действий. Отдельно определяется, кто может просматривать, создавать, изменять, согласовывать, публиковать и удалять информацию.
Права назначаются не по принципу «дать доступ ко всему, а потом ограничить», а исходя из рабочих задач пользователя. Если один сотрудник выполняет несколько функций, ему могут быть назначены несколько предусмотренных ролей.
Закрытые данные отделяются от публичной части и выдаются только после проверки пользователя и его прав. Для чувствительных операций могут применяться дополнительные подтверждения, журналирование действий, ограничения на загрузку файлов и другие меры, предусмотренные требованиями проекта.
Безопасность зависит не только от программного кода. Необходимо учитывать сервер, резервное копирование, обновления, хранение ключей, права администраторов и действия сотрудников. Конкретные требования фиксируются до разработки, а не добавляются общей фразой о «надежной защите».
Можно, но изменение согласованного требования может затронуть интерфейсы, данные, права пользователей, интеграции и уже разработанные функции. Поэтому сначала оценивается влияние изменения на остальные части проекта.
Если новая задача выходит за согласованные границы, она оформляется как дополнительная работа с отдельной оценкой сроков и объема. Изменения не внедряются незаметно и не добавляются в итоговый счет без предварительного согласования.
Проверка начинается не с готового проекта. Сначала согласовываются процессы, структура данных, роли, прототипы и интерфейсы. Во время разработки заказчик получает доступ к рабочей версии на тестовом сервере и может проверять готовые части системы по согласованным сценариям.
Перед запуском проводится приемочное тестирование. Проверяется не только внешний вид страниц, но и права пользователей, операции с данными, формы, документы, уведомления и интеграции. Ошибки и отклонения от согласованных требований устраняются до ввода системы в эксплуатацию.
В большинстве случаев новая версия разрабатывается отдельно и не затрагивает работающий сайт до согласованной даты перехода. Перед запуском подготавливаются домен, сервер, данные, доступы и порядок переключения.
Если проект связан с постоянно изменяющимися заказами, документами или учетными данными, отдельно планируется их финальная синхронизация. Возможность запуска без перерыва зависит от существующей инфраструктуры и должна быть проверена заранее.
После запуска заказчику передаются исходный код, административные и серверные доступы, настройки развертывания, ключи подключенных сервисов и техническая документация в составе, предусмотренном договором.
Система не должна удерживаться у разработчика за счет скрытых доступов или отсутствия исходного кода. Заказчик получает возможность самостоятельно распоряжаться проектом, переносить его на другой сервер и привлекать других специалистов для дальнейшей работы.
После передачи проект может поддерживаться сотрудниками заказчика, другим подрядчиком или мной по отдельному соглашению. В сопровождение могут входить обновления, контроль работоспособности, устранение ошибок, изменение существующих функций и разработка новых модулей.
Запуск не означает, что система должна постоянно переделываться. При нормально определенных требованиях и архитектуре она продолжает выполнять согласованные задачи, а дальнейшие изменения связаны с развитием самой компании, новыми процессами или внешними требованиями.
Связаться со мной
Опишите задачу, текущую ситуацию и ожидаемый результат. Я изучу обращение и свяжусь с вами для обсуждения проекта, сроков и возможного формата работы.
Все поля, помеченные , обязательны для заполнения.