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

Повод для этого разбора — кейс инфраструктурной группы Balfour Beatty о внутреннем приложении в строительстве, опубликованный Microsoft 26 октября 2022 года. Источник представляет позицию поставщика и не является независимой оценкой. Мы не переносим заявленный эффект на другие компании и не используем его как прогноз результата внедрения.

Далее — рекомендации для собственного проекта. Примеры и показатели ниже не описывают процессы или результаты Balfour Beatty.

1. Выбрать одну повторяющуюся операцию

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

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

Если непонятно, кто принимает результат, новый интерфейс сам по себе этот вопрос не решит.

2. Согласовать данные и статусы

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

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

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

3. Устранить ненужное дублирование

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

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

4. Проверить результат на ограниченном пилоте

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

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

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

Решение о расширении стоит принимать по наблюдаемому изменению процесса, а не только по факту запуска приложения.

5. Отдельно проверить технологическую применимость

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

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

Вывод

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

Ответы на эти вопросы дают основу для пилота. Интерфейс и платформа выбираются уже под неё.

Источник: Microsoft — кейс Balfour Beatty, 26 октября 2022 года. Материал поставщика, не независимая оценка.

Напишите «ЗАВОД» — разберём одну повторяющуюся операцию.