Готовая система или разработка под компанию: как проверить выбор до проекта

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

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

Сравнивайте варианты на одном рабочем сценарии

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

Карточка сравнения может выглядеть так:

Положите эту карточку перед всеми кандидатами:

• A — настройка текущего или готового продукта;
• B — тот же продукт с поддерживаемой ограниченной доработкой или интеграцией;
• C — отдельное внутреннее приложение для выбранного процесса.

У всех вариантов должны совпадать роли, данные, обычный случай, исключение и ожидаемый результат. Если поставщик показывает удобное создание задач, а разработчик — красивый отчёт, это ещё не сравнение: кандидаты демонстрируют разные функции.

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

Отделите обязательное правило от пожелания и привычки

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

В учебном примере вариант допустим только при подтверждении всех обязательных условий: C1 и C2 и C3 и C4. Средний балл здесь мешает: удобный интерфейс P1 не компенсирует нарушение C2.

Используйте четыре статуса:

1. Поддерживается и показано — условие подтверждено на выбранном сценарии.
2. Закрывается настройкой или доработкой при указанных условиях — способ ещё зависит от технического подтверждения, прав или сопровождения.
3. Не подтверждено — проверки пока нет. Это не доказательство отсутствия функции.
4. Не подходит при неизменном обязательном условии — известное поведение противоречит принятому правилу.

Команда вправе изменить сам процесс. Например, разрешить исправление закрытой записи без отдельного согласования. Но это новое исходное условие, а не успешное прохождение C2. Запишите, кто утвердил изменение и почему прежний контроль больше не нужен.

Попросите показать готовый продукт с вашими ролями и исключением

Не ограничивайтесь обзором экранов. На обезличенном примере попросите пройти весь маршрут: создать запись, изменить её состояние, выполнить разрешённое действие, получить отказ для запрещённого действия и обработать исключение.

Проверочный лист:

Для реального кандидата зафиксируйте название продукта, редакцию или тариф, версию либо среду, дату и источник подтверждения. В этой статье реальные продукты не оцениваются: условные A, B и C не обозначают конкретные программы.

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

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

Проверьте данные, подключения и возможность выйти из решения

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

Для гибридного варианта отдельно выясните:

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

Слово «API» не подтверждает нужный обмен. Интерфейс может не отдавать историю, не разрешать изменение закрытой записи или работать только при правах, которые компания не готова предоставить.

Пробный выход проводят на обезличенном наборе. Для DEMO-P1, DEMO-T1 и DEMO-E1 нужно прочитать выгруженные ключи, связи и требуемую историю, затем отдельно записать потери. Это условие будущей проверки, а не утверждение, что экспорт уже выполнен в каком-либо продукте.

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

Сравните доработки, эксплуатацию и расходы на одинаковом горизонте

Выберите один горизонт H, одинаковые роли, объём данных и состав сценария. Для каждого варианта соберите три группы расходов:

TCO(H) = Launch + Operation(H) + ChangeExit(H)

• Launch — настройка или разработка, подготовка и перенос данных, обучение и проверка;
• Operation(H) — применимые лицензии или размещение, поддержка, обновления и резервирование;
• ChangeExit(H) — изменение правил, совместимость, экспорт или переезд и передача знаний.

Не каждая статья обязательна для каждого варианта. Например, отдельная лицензия может уже входить в действующую подписку, а модель ИИ этому процессу вообще не нужна. Сначала установите применимость статьи, затем получите сумму и источник.

В исходных данных нет денежных величин, поэтому итог честный: TCO не рассчитан до получения трёх сопоставимых наборов сумм. Неизвестное значение нельзя заменить нулём. Из этой матрицы также нельзя вывести окупаемость, экономию или универсально самый дешёвый вариант.

Готовая подписка не означает автоматического выполнения правил компании. Собственная разработка не означает бесплатного сопровождения. У гибрида появляется отдельная зависимость: после изменения платформы кто-то должен проверить и при необходимости обновить связку.

Зафиксируйте условное решение и следующий проверочный этап

Решение должно показывать не только выбранное направление, но и его границы. Для каждого обязательного критерия заполните пять полей:

Например, решение может звучать так: «Проверить ограниченную доработку B на C1–C4. Не утверждать покупку, разработку всего контура или перенос рабочих данных до подтверждения подключения, прав, экспорта и владельца сопровождения».

Выбор пересматривают, если:

• штатная настройка A подтверждённо выполняет C2 и C4 — тогда можно вернуться к более узкому варианту;
• B не подтверждает поддерживаемое подключение, C2, C3 или C4 — тогда гибрид не утверждают;
• обязательное правило осознанно изменено владельцами процесса — тогда матрицу составляют заново с новым условием;
• потери при выходе признаны неприемлемыми — кандидат исключают или меняют состав решения.

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

Если для ограниченного процесса нужна отдельная система, Switch On AI помогает описать роли, данные, действия, подключения, эксплуатацию и критерии передачи в рамках услуги внутренней системы под согласованный рабочий процесс. Сначала всё равно проверяются действующие средства и возможность ограничиться настройкой или модулем.

Учебная матрица: когда достаточно доработки

EX-T01. Учебное сравнение: кандидаты A/B/C и все сведения о них вымышлены. Продукты, лицензии, аккаунты и клиентские данные не тестировались.

Вход. Проектная команда хочет связать задачу с записями времени и разрешать исправление закрытого периода только через согласованное действие с историей. Нужны роли и перенос данных со связями. Это правило условной компании, а не универсальный стандарт.

Сценарий. Проект DEMO-P1 → задача DEMO-T1 → запись времени DEMO-E1. После переименования задачи связь сохраняется. Попытка исправить закрытую запись проходит только предусмотренный маршрут и оставляет основание.

Для B учебная последовательность проверки выглядит так:

1. C1: переименовать DEMO-T1 и убедиться, что DEMO-E1 по-прежнему связана с той же задачей.
2. C2: запросить исправление закрытой DEMO-E1; действие должна выполнить только предусмотренная роль, а система — сохранить основание и историю.
3. C3: пройти один разрешённый сценарий и один запрещённый; проверять нужно данные и операцию, а не только кнопку.
4. C4: выгрузить обезличенные DEMO-P1, DEMO-T1 и DEMO-E1, прочитать ключи, связи и требуемую историю, затем перечислить потери.

Это ожидаемый порядок будущей проверки, а не отчёт о выполненном испытании.

Вывод по условиям задачи. Следующий шаг — ограниченная проверка B: она исследует разрыв C2, сохраняя условно показанные C1 и C3 текущего трекера. A как есть не закрывает обязательный C2. C остаётся резервом для узкого процесса; его реализация и эксплуатация ещё не доказаны. Покупка и полная замена системы не утверждены.

Исключение и пересмотр. Если для B не подтверждены поддерживаемое подключение, C2, C3 или перенос C4, гибрид утверждать нельзя. При неизменном правиле следует оценить узкое отдельное приложение. Если штатная настройка A доказанно закрывает C2 и C4, нужно вернуться к A. Это новые основания решения, а не универсальный вывод о продуктах.

Чтобы применить метод к своей компании, замените DEMO-P1, DEMO-T1 и DEMO-E1 обезличенным примером, назначьте владельцев C1–C4 и заполните расходы по реальным предложениям. Затем можно обсудить варианты внутренней системы для вашего процесса со Switch On AI. Для первого разговора достаточно одного сценария, обязательного исключения и перечня используемых программ; пароли, рабочие базы и финансовые сведения через открытую форму не нужны.