Отраслевые программные решения для Ваших рабочих процессов

Отраслевая принадлежность — хорошая отправная точка, но сама по себе она не определяет объём проекта. Два отеля могут использовать разные способы бронирования, а два производителя — предоставлять разную техническую документацию. Модель оказания услуг, способ принятия решения пользователем и команду, которая будет поддерживать актуальность данных, необходимо оценивать в совокупности. Рекомендации на этих страницах — не фиксированный перечень пакетов, а рабочие вопросы, помогающие разграничить потребности.

Эти процессы разбираем на конкретных примерах и с компаниями по всей Турции, и с бизнесом из Европы, стран Персидского залива и СНГ, который рассматривает аутсорсинг разработки. Страна не заменяет описание задач отрасли: отдельно оцениваем местные правила работы с данными, язык пользователей и существующие системы. Удалённые встречи проходят на английском или турецком.

Какая информация нужна до отправки заявки?

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

В промышленности и производстве специалист по закупкам может искать технические характеристики. В строительстве и архитектуре важны характер и качество выполненных работ, а также объём проекта. В заявке на ремонт или техническое обслуживание тип устройства и описание неисправности делают первое обращение содержательным. Хотя во всех этих сферах можно использовать одно и то же универсальное поле для сообщения, сценарий, который запрашивает сведения, необходимые для конкретной задачи, позволяет более последовательно оценивать обращения.

Кто отвечает за публикацию информации?

Кто будет менять даты учебных программ в образовательной организации, кто будет утверждать сведения о врачах и услугах в клинике, кто будет проверять соответствие текстов профессиональным требованиям в юридической фирме? Это не детали, которые можно отложить до завершения дизайна. Когда известны ответственный за публикацию со стороны компании и порядок проверки, интерфейсы управления планируются с учётом этих условий. Техническая разработка не заменяет утверждение компанией контента с точки зрения профессиональных или правовых требований.

Рабочие процессы после получения заявки

Запрос на запись не всегда означает подтверждённую запись. Перечень позиций в запросе коммерческого предложения также не обязательно автоматически превращается в заказ. Формулировка, которую видит пользователь, должна описывать действие, которое компания действительно может выполнить. Необходимо обсудить, кто будет рассматривать заявку, при отсутствии каких сведений потребуется связаться с заявителем и как будет отслеживаться статус. Так обещание, данное в пользовательском интерфейсе, остаётся согласованным с внутренними процессами.

Четыре различия, на которые стоит обратить внимание в отраслевых руководствах

• Отделяйте информацию, которая непосредственно помогает пользователю принять решение, от исключительно декоративного контента.
• Рассматривайте потребность в презентационной странице отдельно от управления постоянно обновляемыми записями.
• Не смешивайте форму отправки заявки с операциями управления запасами, календарём или платежами.
• Определите, какие данные предоставляет существующая система, а какие сведения компания будет вводить вручную.

После такого разграничения становится понятнее, где заканчивается объём работ по веб-дизайну и где начинается потребность в заказной разработке ПО. Например, публикация актуальной информации об услугах и расчёт загрузки — разные задачи. Распространённость функций в отрасли не означает, что они необходимы Вашей компании: нужно также оценить частоту их использования и то, какие рабочие процессы они поддерживают.

Примеры проектов и рекомендуемый объём работ — не одно и то же

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

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