Система физико-экономической оценки добычи полезных ископаемых
Роль
Senior Product Designer / Lead Designer
Продукт
B2B Enterprise On-premise
Индустрия
Нефтегазовая отрасль
Период
2022 — 2024
Продукт предназначен для оценки рентабельности и планирования разработки объектов добычи полезных ископаемых. Он состоит из нескольких модулей, каждый из которых отвечает за один из этапов проекта: расчет физических показателей, оценка сроков проекта и объема добываемых ресурсов, оценка обустройства инфраструктуры объектов, расчет стоимости и рентабельности проекта. Последний этап покрывает модуль «Экономика», о котором пойдет речь в данном кейсе.
Цель
Создание инструмента, который позволит снизить количество ошибок и неверных прогнозов (что, в конечном счете, приводит к невыгодным инвестициям) за счет прозрачности процесса экономической оценки проекта и автоматизации связи между несколькими этапами работы разных специалистов.
Проблематика
- Непрозрачный алгоритм расчета и сложность проверки данных
- Высокая вероятность ошибок и подмены значений
- Отсутствие единого источника данных (много версий файлов на каждом этапе)
- Необходимость ухода от Excel из-за санкций
- Отсутствие аналогов на рынке
User Story Map
Гипотеза 1
Проблема
Недостаточная точность расчета из-за сложности настройки входных значений для нескольких объектов разработки и проекта в целом
Решение
Возможность задания значений параметров на уровне проекта и отдельных объектов с подсветкой кастомизированных параметров
Предположения
Понятная структура и механика ввода значений параметров
Критерии успеха
Пользователь может настроить более точный расчет с учетом отклонений на уровне отдельных объектов
В MVP была придумана механика с двумя режимами ввода данных - проект и объекты. Значения параметров в объектах по умолчанию наследовались с уровня проекта. То есть значения объекта были либо связаны с проектом, либо отвязаны и тогда пользователь мог их изменить. При переходе на уровень проекта, в этом параметре отображался индикатор того, что значение отличается у некоторых объектов, а в боковой панели можно было увидеть конкретные значения.
В ходе тестирования MVP стало понятно, что разделения на проект и объекты не существует, но чаще всего у всех объектов, кроме некоторых, будут одинаковые значения параметров. Первоначальное решение можно было легко адаптировать под такой подход и большая часть механики сохранилась. Но пришлось пересмотреть отображение отличающихся параметров, так как выяснилось, что большая часть параметров, которыми оперируют пользователи являются векторными (то есть, имеют разные значения в разные периоды) и необходимо отображать все их значения одновременно, боковая панель для этого не подходила.
Гипотеза 2
Проблема
Высокая вероятность ошибок и подмены значений за счет возможности замены формул на значения заданные вручную
Решение
Жестко заданный алгоритм расчета без возможности редактирования расчетных значений
Предположения
Пользователь не должен иметь возможности редактировать алгоритм расчета во избежание ошибок и подмены значений
Критерии успеха
Пользователь-аналитик не совершает ошибки, проверяющий менеджер избавляется от необходимости проверять расчет
Для настройки расчета использовался уже существующий в системе механизм сборки цепочки расчета из нескольких компонентов. В компоненты были зашиты определенные формулы, использующие исходные параметры, значения которых задают пользователи. Изменить или увидеть эти формулы было нельзя. При тестировании MVP оказалось, что это слишком радикальный подход. Пользователям важно было видеть и гибко настраивать алгоритм расчета.
Почему так произошло
При проектировании MVP мы совершили серьезную ошибку – доверились мнению стейкхолдера, не проверив гипотезу на пользователях. Получив доступ к пользователям, я не верифицировала общий флоу, а лишь провела юзабилити тестирование отдельных сценариев. Пользователи были недостаточно вовлечены, чтобы заметить недочеты за пределами тестируемых сценариев и поселить в нас сомнения. Мы следовали видению стейкхолдера и не смогли на раннем этапе понять, что в самом флоу есть большие недостатки.
Гипотеза 3
Проблема
Непрозрачный алгоритм расчета
Решение
Визуальный редактор формул с возможностью просмотра в виде иерархической структуры
Предположения
Легко проследить цепочку расчета и понять как получен результат
Критерии успеха
Пользователь быстро понимает алгоритм расчета, видит значения входных и расчетных параметров на одном экране, без необходимости перехода по разным ячейкам, листам и файлам Excel
Пользователям нужен был инструмент, который способен был реализовать сложные расчеты, доступные в эксель, но при этом был более прозрачным.
Для решения этой задачи мной был спроектирован интерфейс визуального редактора – конструктора расчетов, в котором пользователи могут задавать алгоритм расчета параметров с использованием исходных данных, данных других модулей, встроенных функций и математических операций.. Для того, чтобы обеспечить прозрачность и понятность, был добавлен режим иерархического просмотра формул, позволяющий увидеть всю цепочку расчета в виде вложенных формул.
Гипотеза 4
Проблема
Процесс расчета не линеен, пользователь экспериментирует с разными конфигурациями расчета для нахождения точки окупаемости
Решение
Возможность создания нескольких вариантов исходных данных в рамках одного проекта
Предположения
Удобное пространство для экспериментов с сохранением разных версий и без необходимости создавать новые проекты
Критерии успеха
Пользователь может создавать разные версии данных в одном пространстве и подставлять их в расчет
Результат
В итоге у нас получился инструмент, способный заменить excel и при этом обеспечить бОльшую прозрачность. Мы смогли связать расчет экономики с другими частями бизнес-процесса, без необходимости передавать данные вручную. А спроектированный мной конструктор расчетов был переиспользован в других модулях системы.
