Готовая система или собственная разработка — вопрос, который возникает почти всегда

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

Оба подхода встречаются достаточно часто.

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

Однако на практике требования обычно оказываются значительно шире.

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

Именно поэтому выбор подхода редко бывает очевидным.

Когда организации задумываются о собственной разработке

Собственная разработка обычно рассматривается по нескольким причинам.

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

Типичные аргументы в пользу собственной разработки выглядят знакомо:

«у нас специфические требования»;
«готовые системы слишком тяжёлые»;
«проще сделать своё»;
«нужна полная адаптация под наши процессы»;
«не хочется зависеть от поставщика».

Подобная логика вполне понятна.

Но при принятии решения важно учитывать не только функциональность первой версии продукта, но и полный жизненный цикл системы.

Что обычно входит в собственную разработку каталога сотрудников

На старте задача действительно может выглядеть компактно.

Например:

поиск сотрудников;
телефонный справочник;
подразделения;
карточки пользователей;
простая оргструктура.

Но постепенно проект начинает расти.

Часто добавляются:

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

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

Плюсы собственной разработки

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

Гибкость процессов

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

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

Контроль над архитектурой

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

Для части компаний это принципиальный фактор.

Независимость в развитии продукта

Функциональность развивается в собственном темпе и в соответствии с внутренними приоритетами.

Не требуется ждать дорожную карту поставщика или адаптироваться под общую продуктовую стратегию внешней системы.

Какие сложности часто появляются в собственной разработке

Несмотря на преимущества, у собственного решения обычно возникают и менее очевидные издержки.

Сроки почти всегда оказываются больше ожидаемых

Многие внутренние проекты начинают с оценки в несколько недель или месяцев.

Но после появления реальных требований сроки начинают расширяться.

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

В результате проект, который должен был закрыть одну задачу, постепенно превращается в полноценный внутренний продукт.

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

Один из самых частых просчётов — воспринимать внедрение как завершённую задачу.

На практике после первой версии начинается основной этап эксплуатации.

Требуются:

исправления ошибок;
обновления;
развитие функциональности;
сопровождение инфраструктуры;
адаптация под новые процессы;
поддержка пользователей.

Фактически организация берёт на себя роль постоянного производителя программного продукта.

Возникает зависимость от внутренней команды

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

Если сотрудники меняются, переключаются на другие задачи или покидают компанию, поддержка может быстро стать проблемой.

Для внутренних корпоративных систем это достаточно распространённый сценарий.

Когда готовое решение оказывается практичнее

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

Такой подход часто позволяет:

сократить сроки запуска;
уменьшить проектные риски;
использовать уже проверенную функциональность;
снизить нагрузку на внутреннюю ИТ-команду.

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

Что обычно проверяют в готовом решении

При выборе внутреннего каталога сотрудников организации обычно смотрят не только на интерфейс или поиск контактов.

Часто оцениваются следующие критерии:

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

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

Российский контекст: инфраструктура и импортозамещение

Для части российских организаций выбор решения связан не только с функциональностью.

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

Поэтому при выборе внутреннего каталога сотрудников часто оцениваются:

возможность локальной установки;
работа во внутренней сети;
отсутствие зависимости от внешних облаков;
совместимость с существующей инфраструктурой;
контроль над данными организации.

Именно по этой причине многие проекты ориентируются на решения, рассчитанные на внутренние корпоративные среды.

Как обычно принимают решение

Универсального ответа здесь нет.

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

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

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

Итог

Выбор между готовым решением и собственной разработкой внутреннего каталога сотрудников редко сводится только к функциональности.

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

Для части организаций собственная разработка становится правильным выбором.

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

К этому классу решений относится и Оргнавигатор.