Если система работает со скрипом: цели автоматизации и паспорт проекта

❤️Пару дней назад я писала про треш-комментарии, с которыми к руководителям проектов приходят заказчики. Откликнулась Настя, и вот ее комментарий:
«Всё автоматизировано, но с таким скрипом работает, что руками быстрее!»

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

🤩Это прекрасное Но. Целью любой автоматизации является система, которая позволяет принимать решения на основе полученных данных. Иногда про это забывают😬 и автоматизируют только бизнес-процесс, чтобы сделать работу удобной для пользователей.

💻Если к вам приходят с системой, которая плохо работает, первое на что стоит посмотреть - это то, какие глобальные цели были у системы. Для аналитических систем это, как правило, вывод дашбордов с ключевыми показателями эффективности деятельности. А нет данных - нет дашбордов. Работает Капитан очевидность!😎 Ну а пользователей устраивают и иксельки. Так было всегда.

Что делать Насте?

▪️▪️Выяснить, какие решения принимаются на базе данных, которые должна была собирать система. Кто является пользователями этой аналитики и какие у них ожидания.
▪️▪️Убедиться, что система соответствует этим целям. Если да - идем думать как оптимизировать скорость работы/процессы. Если нет - см.п.3.
▪️▪️Пишем паспорт проекта. По-старинке, на 4х листах, бизнес-потребность, цели, задачи, образ результата. Даже если вам говорят, что уже все написано до вас. Согласовываем все с заказчиком и стейкхолдерами. Т.е. с теми лицами, кто будет пользоваться аналитикой и иметь с этого некий профит в виде точности расчетов/обоснований для принятия решений.

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

▪️▪️После того как паспорт согласован - смотрим что делать: изменять текущую систему или все ломать и строить заново. В этот момент может возникнуть микроконфликт🪓🪓🪓, т.к.заказчик вполне может преследовать цель "все переделать". И тут важны аргументы. Возможно, на этапе discovery вам придется проектировать две версии системы. Реалии корпоративной жизни😂▪️▪️ Именно для этого изучают системную архитектуру - чтобы можно было до привлечения подрядчика/разработки что-то предложить и прикинуть рамки оценки.

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

👩‍💻🧙‍♂️100 млн лет назад я писала про тестирование процессов методом "Волшебника изумрудного города" (ссылки на старые посты не работают, но найти можно в поиске). Думаю, прежде чем чинить скорость работы - нужно проверить что бизнес-процесс действительно соответствует пользовательской ментальной модели. Но это уже совсем другая история...