Когда нужно индивидуальное ПО? Случаи, когда готового продукта недостаточно

Индивидуальное программное обеспечение — это веб-, мобильное или бэк-офисное приложение, спроектированное на основе бизнес-правил организации, ролей её пользователей и потребностей в интеграции. Если готовый продукт решает вашу задачу, индивидуальное ПО не нужно; главное — вовремя заметить, где готового продукта становится недостаточно.

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

Шесть ситуаций, указывающих на индивидуальное ПО

1. Рядом с программой работает «теневая» система. Вы пользуетесь готовым продуктом, но настоящий учёт по-прежнему ведётся в таблице или в цепочке писем. Это самый явный признак того, что продукт не покрывает реальный ход работы.
2. Правила согласования и назначения у вас особые. Ваш процесс заявки, согласования, назначения, сроков и статусов меняется в зависимости от суммы, подразделения или типа клиента и не укладывается в готовые схемы.
3. Каждая роль должна видеть свой экран. Клиенту, полевой команде, руководителю и аудитору нужны разные права и разные представления; ролевая структура продукта этого не обеспечивает.
4. Обмен данными с другими системами обязателен. Данные должны регулярно обмениваться с ERP, бухгалтерией или внешним сервисом, а готовые подключения этого не охватывают.
5. Руководство хочет другие показатели. Нужные KPI по ролям, отчёты и операционная наглядность выходят за рамки стандартных отчётов продукта.
6. Операции интенсивные и повторяющиеся. Для команды, которая сотни раз в день выполняет одну и ту же операцию, каждый лишний щелчок — большая потеря; такой команде нужен эффективный интерфейс управления.

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

Готовый продукт всё ещё может быть правильнее

Индивидуальное ПО — не ответ на любой вопрос. В следующих случаях чаще всего разумнее продолжать с готовым продуктом:

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

Индивидуальное ПО — не поставка, а продукт, которым компания должна владеть; в день запуска оно не заканчивается, а начинает учиться.

Реальные риски индивидуального ПО

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

Как идёт работа над индивидуальным ПО?

В индивидуальной разработке до экрана проектируется процесс, до списка функций — архитектура пользователей, данных и бизнес-правил. В проектах по Индивидуальному ПО YazSis придерживается четырёх этапов:

1. Исследование: выявляются цель, пользователи, данные и бизнес-правила. На этом этапе пишется не код, а общее понимание.
2. Пользовательский опыт и архитектура: проектируются сценарий использования и устойчивая техническая структура; проясняются роли, модель данных и точки интеграции.
3. Разработка и тестирование: приложение разрабатывается модулями и проверяется на реальных сценариях.
4. Запуск и поддержка: система вводится в работу, использование измеряется, а улучшения вносятся по обратной связи.

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

Три вещи, которые нужно подготовить до начала

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

Подробнее о наших веб-, мобильных и бэк-офисных решениях под вашу компанию можно узнать на странице Индивидуальное ПО.