6 принципов успешного внедрения enterprise-проектов

Спрос на собственные enterprise-решения сохраняет положительный тренд: после ухода зарубежных вендоров компании начали перестраивать свой ИТ-ландшафт и переходить к разработке внутренних продуктов.

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

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

Определите целевые бизнес-эффекты и сделайте их главными ориентирами проекта

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

Определите измеримые цели. Зафиксируйте текущие показатели и задайте целевые значения к конкретному сроку. Например: сейчас обработка обращения занимает A минут, результат заявитель получает через B дней. Цель — сократить обработку на x%, а срок получения результата — на y%.

Подключите аналитику с самого начала. Настройте BI-дашборды в первые недели проекта. Так вы заранее выделите приоритетные метрики и сможете сфокусировать на них работу команды в нужный момент.

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

Согласуйте ожидания топ-менеджеров и пользователей

Топ-менеджерам нужна управленческая прозрачность и детальная статистика. Пользователям — скорость, простота и минимум действий. Если эти требования не проверить на совместимость заранее, система либо будет неудобной для сотрудников, либо не даст руководству тех данных, на которые они рассчитывают.

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

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

Продумайте внедрение и поддержку ещё до того, как начнёте писать код

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

Что важно предусмотреть заранее:

1. Сценарий внедрения и комплект документации. Материалы по работе с системой должны быть подготовлены параллельно с разработкой.
2. Обучение пользователей. Лучше всего работает комбинация коротких видеоинструкций и амбассадоров изменений — сотрудников из разных отделов, которые проходят углублённое обучение и могут быстро объяснить коллегам, как устроены ключевые сценарии.
3. Прозрачные правила поддержки. Согласуйте, как распределяются обращения по критичности, в какие сроки принимаются и закрываются запросы, что делать при инцидентах.
4. Пилотный запуск. Старт на небольшой группе пользователей помогает оценить реальный объём запросов, увидеть, с какими вопросами чаще всего сталкиваются сотрудники, и понять, справляется ли первая линия поддержки с нагрузкой.

Учитывайте требования информационной безопасности на этапе предпроектной аналитики

Любой enterprise-проект существует внутри инфраструктуры компании, а значит — в зоне прямого влияния службы информационной безопасности. Если ограничения и требования ИБ выявляются слишком поздно, проект либо теряет часть функциональности, либо вынужденно переписывается, что отражается на сроках, стоимости и качестве решения. И это только оперативные последствия. Отложенные — утечки данных, проблемы с хранением персональной информации, блокировка интеграций и работа системы «в полсилы», когда часть функций просто не работает в корпоративной среде.

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

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

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

Разрабатывайте сильный UX/UI с самого начала

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

Прорабатывать интерфейс лучше в тесном контакте с реальными пользователями. Фокус-группы помогают увидеть, какие элементы действительно непонятны, а какие вызывают только временное сопротивление из-за новых привычек. Такой подход позволяет отделять объективные неудобства от естественного периода адаптации, который есть в любом проекте.

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

Заранее планируйте интеграции и закладывайте на них ресурсы внутренних команд

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

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

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

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