Путь внедрения программного обеспечения в тысячу миль начинается с нулевого этапа (Джеймс Монаган)

Поздравляем. Вы решили внедрить какое-то программное обеспечение и хотите, чтобы оно было успешным. Будет ли это Agile, или Waterfall, или Lean, или Scrum, или что-то совсем другое. Хотя успешная реализация проекта имеет свои собственные требования для его запуска,
Есть множество вещей, которые следует учитывать перед стартом.

Была ли адекватно определена целевая операционная модель?

Спешное внедрение новой технологии сопряжено с многочисленными ловушками, но самая распространенная из них — это начало развертывания/интеграции системы без учета того, как будет выглядеть общая картина в целом, когда она будет завершена. Слишком много проектов свернуто
в самом начале, потому что какая-то ключевая часть технологии не была учтена в общей схеме. Со всеми финтехами и новаторами на рынке сегодня все будут стремиться беспрепятственно интегрироваться друг с другом, но без полного понимания.
of КАК вы хотите, чтобы они подключились, и по какой причине вы можете легко переделать свою целевую операционную модель на полпути, и вам придется выбросить все усилия и ресурсы, которые вы потратили до сих пор. Это все равно, что пытаться построить самолет, пока
полетать на нем или заменить автомобильную шину во время вождения. Типичные TOM будут иметь систему типа управления взаимоотношениями с клиентами (CRM), которую может использовать клиент, работающий с персоналом, подключаясь к системе управления жизненным циклом клиента, включающей рабочий процесс и механизм правил.
передать необходимые задачи соответствующим людям для завершения ввода данных/загрузки документов/проверки и проверки. Может существовать система управления мастер-данными (MDM), которая рассматривается как источник записи/золотая копия, но слишком часто это разрозненная система.
система нескольких агрегированных или интегрированных хранилищ данных с различными системами, которые могут обновлять записи. Могут быть системы транзакций/торговли/кредитования со встроенными или интегрированными службами мониторинга транзакций. Могут быть сторонние поставщики данных/документов.
или новости/негативные новости/проверочные цели. Все или некоторые из них могут быть облачными или локальными. Итак, еще раз, я спрашиваю вас, думали ли вы, где эта новая технология вписывается в ваш общий ТОМ, и является ли она окончательной версией или вы
интегрировать его в текущую настройку, но планирую изменить это в будущем

Что касается всех ваших текущих систем, как долго вы планируете поддерживать их?

Существует распространенная ошибка, известная как заблуждение о невозвратных издержках: только потому, что вы потратили X долларов/евро/фунтов на систему, это слишком далеко, чтобы признать поражение и отказаться от нее. Или что он не сломан и не требует ремонта. Или что он слишком укоренился
в текущих системах, чтобы иметь возможность удалить или заменить его. Если это так, то вы, вероятно, столкнулись с единственной точкой отказа, даже не осознавая этого. Современные технологические решения гибки и должны быть рассчитаны на изменения. Ранее слияния / поглощения
или объединение систем вынуждает интегрировать технологии, и обычный процесс заключается в том, чтобы просто заставить их работать. К ним следует относиться как к возможности пересмотреть то, как что-то делается, и стремиться к более эффективному способу. Второй
к этому большинство новых технологий будут иметь или претендовать на наличие аналогичных предложений/модулей/функций, таких как отчетность, информационные панели, рабочий процесс, механизмы правил управления делами, студия конфигурации. Целью этого является обращение к максимально широкой аудитории и имеет
некоторые люди думают: «Зачем мне покупать Х, если у Y уже есть такая возможность?». Но с учетом этого, действительно ли вы хотите превратить свою CRM в систему мониторинга транзакций? Или ваша учетная запись в шлюз для вашего MDM? Или ваш MDM в качестве принципала
точка ввода данных. Вы знаете, что получите тысячи записей с телефонными номерами 12345678.

Персонал/Роли

Чтобы любая реализация была успешной, у вас будут определенные роли на обеих сторонах проекта. Ваш и продавцов. Это, очевидно, зависит от бюджета, объема и сроков. У вас может быть 4-недельная облачная реализация, для которой требуется 2 сотрудника из
поставщика, или это может быть 10 этапов 12-недельных основных выпусков с 2-недельным гибким подходом к требованиям, состоящим из бизнес-аналитиков / продуктовых аналитиков, разработчиков, экспертов в предметной области, тестировщиков обеспечения качества, всем из которых нужны как младшие, так и старшие роли, проект
менеджеры по каждому направлению бизнеса/региона/юрисдикции и программный менеджер, чтобы все это контролировать. Добавьте к этому спонсора проекта, и вы легко поймете, почему корпоративное программное обеспечение становится дорогим, иногда непомерно дорогим. Это также до того, как вы рассмотрите уровни персонала
что вам нужно выделить, чтобы соответствовать. Не забывайте, что ваши сотрудники, участвующие в этом проекте, будут отсутствовать в повседневной работе в течение значительного времени. Важно убедиться, что персонал поставщика имеет опыт работы и не
недавно нанят для удовлетворения спроса вашего проекта.

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

Перенос данных

Одной из основных тем, связанных с новым программным обеспечением, является доступ к данным и/или перенос данных. Если новая система будет запрашивать вашу текущую базу данных или базы данных по мере необходимости, когда она получит доступ, какие пользователи имеют какие разрешения
для доступа к нему, является ли доступ только для чтения или пользователи могут редактировать или создавать новые записи, и когда они обновляют центральную запись, какие системы имеют приоритет для внесения этих изменений? Что, если другая система попытается внести изменения, пока другой пользователь
вашей новой технологии в настоящее время редактирует его? Означает ли это, что теперь все запросы на редактирование данных должны направляться через эту новую технологию? Что происходит, когда все новые технологии требуют одинакового порядка приоритетов? Это только для активных систем записи клиентов.
А как насчет создания новой консолидированной единой системы? Стоит ли применять подход «большого взрыва» для переноса всех данных в первый день? Представьте риски. Как насчет переходного периода, например, когда проверка запланирована, вы используете один или несколько источников для проведения проверки?
а затем отправьте чистую запись в новую центральную базу данных. Вместо этого это позволило бы осуществлять миграцию в течение 12–18 месяцев. Это не универсальный подход. Это все, прежде чем вы начнете рассматривать дубликаты.

Интеграции

При рассмотрении вопроса о добавлении новой технологии в вашу экосистему вы должны убедиться, что она будет без проблем работать с вашей текущей настройкой. Первоначально у этого есть 2 варианта: либо чистое новое дополнение для решения конкретной проблемы, либо замена существующей системы.
или системы на месте. В любом случае вы хотите убедиться, что у него есть доступ к соответствующим системам, которые ему нужны как для восходящего, так и для нисходящего потребления. Вы также должны быть уверены, что все существующие подключения к выводимой из эксплуатации системе можно сохранить.
Существует также вопрос о разрешении, который постоянно упускается из виду. Управление доступом пользователей для управления разрешениями, которые пользователи имеют для новой технологии для данных, к которым у нее есть доступ, а также для обеспечения отсутствия требований к разрешениям администратора.
Но когда в будущем вы добавите более новую технологию, нужно ли будет усовершенствовать контроль доступа для всех старых систем на тот момент? Как и в предыдущем случае, давайте не будем забывать о необходимости определить, какая технология имеет приоритет для изменения/обновления данных. В противном случае
Как убедиться, что система А вносит изменения сегодня, система Б отменяет их завтра, а система А повторяет попытку на следующий день?

Доступ к системе — политики информационной безопасности

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

Покупатели против пользователей

Участвуют ли конечные пользователи новой технологии в процессе принятия решений? Какой смысл принимать решение от имени других пользователей, если в итоге они решат, что то, что строится, не подходит для их целей. Битва между бизнесом и
ЭТО постоянно происходит повсюду и колеблется взад и вперед в зависимости от того, кто принимает решения. Слишком часто ожидается, что дизайн системы идеально решит любую проблему для каждого пользователя. Над разработкой технологии для решения на 100%
является замечательным, но в конечном счете ресурсоемким предприятием. Первоначальная цель должна состоять в том, чтобы решить для большинства и дождаться успешной доставки, прежде чем пытаться пограничные случаи. Эти последние 20% или 10% выпусков не должны препятствовать основной цели приобретения.
технологии, но слишком часто она становится всепоглощающей. Вопрос, который нужно задать себе, заключается в том, что определенно требуется в первый день, и ограничьте свои варианты подмножеством, поскольку ответ по умолчанию без всегда, всегда, все.

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