Целостная экосистема или набор модулей: два подхода к внедрению

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

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

Что такое экосистема

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

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

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

Комплексный взгляд на экосистему vs потока изменений

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

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

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

Но как отделить зерна от плевел и понять, стоит ли реализовывать требуемые заказчиком изменения? Ведь если поменять в одном месте, возникают дополнительные риски: все точечные доработки либо станут несвязанными, либо потребует много сил и времени на переделку.

Ценность изменений: а вдруг они не нужны?

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

Выявление проблемы. Какую проблему клиента решает эта доработка? Помогает ли она достичь результата или лишь маскирует его неполучение?

Определение функционального заказчика. Кто бизнес-заказчик доработки? Подтвердил ли он требования, видит ли получение пользы?

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

Назначение менеджеров для контроля. Кто и как будет контролировать использование доработки? Кто будет ответственным за результаты? Кто будет следить за синхронизацией реальных и спроектированных сценариев использования?

Наличие пользователей. Кто и как будет применять реализованные изменения? Кто и какую дополнительную ценность производит с использованием результатов этих доработок?

Поиск готового решения. Кто может ответить, есть ли уже готовое решение в ИТ-системе? Как проверить, внедрен ли уже похожий механизм или инструмент?

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

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

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

Как оценить успешность изменений

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

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

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