ОСНОВНЫЕ ПРОБЛЕМЫ, ВОЗНИКАЮЩИЕ ПРИ РЕАЛИЗАЦИИ ПРОЕКТОВ ПО УПРАВЛЕНИЮ ИТ-АКТИВАМИ
ВВЕДЕНИЕ
Большинство Заказчиков задумывается о внедрении процессов по учету программных и аппаратных ИТ-активов, когда понимает, что в информационном хаосе жить больше нельзя и организация несет от этого дополнительные затраты, а также рискует получить неприятности при аудите со стороны всевозможных вендоров.
Исходя из этой вводной мы получаем целый ряд проблем, с которыми предстоит столкнуться в ходе управления проектом в данной сфере. Это и «грязные» исходные данные, и отсутствие стандартизации при организации закупок, и не налаженное взаимодействие со смежными видами деятельности (бухгалтерский и финансовый учет, дискаверинг, ITSM) и т.д. Давайте попробуем остановиться на самых популярных проблемах поподробнее и поймем, каким образом избежать или минимизировать их появление.
ПОЛЬЗА ОТ ВНЕДРЕНИЯ ПРОЦЕССА УПРАВЛЕНИЯ ИТ-АКТИВАМИ
Основной проблемой является то, что с момента этапа проектирования до фактического внедрения проходит достаточно большое количество времени, поэтому Заказчик не видит практической пользы от внедрения и слабо заинтересован в результате. Плюс есть устоявшаяся практика ведения учета ИТ-активов с помощью Microsoft Excel, а отказываться от привычной практики никто не хочет. Против использования Excel есть ряд причин:
- данные можно случайно удалить/изменить;
- все данные вносят в ручном режиме;
- нельзя выгрузить информацию в бухучет без дополнительных интеграций;
- нельзя единовременно ввести большой объем данных.
Если остановится на основных преимуществах внедрения ITAM, то это:
- централизованный учет затрат;
- поддержка парка оборудования в актуальном состоянии (как пример, поиск неиспользуемых активов и отказ от их технического обслуживания);
- нормализация процесса закупок;
- возможность выбора оптимальной модели лицензирования;
- уменьшение рисков преследования за несоблюдение лицензионных соглашений.
Допустим, Заказчик проникся приведенными аргументами и готов всячески содействовать с вами для получения качественного продукта в конце работ. Теперь самое время пройтись по «болевым» точкам проекта и не допустить ошибок на старте. Разберем их подробнее.
ИНТЕГРАЦИИ
На первых шагах хорошей практикой будет определить перечень систем, с которыми придется интегрироваться в ходе проекта. Зачастую для корректной интеграции они также потребуют доработки, и чем раньше их владельцы об этом узнают, тем больше шансов на успех. Не лишним будет узнать и о текущей нагрузке, так как в моей практике был случай отказа от интеграции сразу же после ее запуска из-за высокой нагрузки на смежную систему при двустороннем обмене данными. Также рекомендую предостеречь Заказчика от желания сделать из системы по управлению ИТ-активами универсальный справочник, содержащий в себе все атрибуты, какие только можно получить из всевозможных источников данных. Это увеличит нагрузку на нее и соответственно уменьшит скорость работы, да и затруднит поиск по такому большому количеству параметров.
Если при реализации проекта планируется взаимодействие с ITSM-системой, то в первую очередь необходимо определить перечень КЕ, которые будет учувствовать в процессе управления конфигурациями. Жизненный цикл КЕ и ИТ-актива по большей части пересекаются, поэтому для исключения двойного ввода в рамках учета и актуализации данных имеет смысл спроектировать обмен данными между CMDB и AMDB.
Касаемо интеграций также важно обратить внимание на автодискаверинг. Как показывает опыт, далеко не все категории ИТ-активов, которые интересуют Заказчика, попадают в охват дискаверинга. Это касается и аппаратных и программных активов. Если не учесть это в начале работ, то о внедрении управления активами программного обеспечения (Software Asset Management, SAM) можно забыть, а зачастую именно соблюдение правил лицензирования больше всего интересует Заказчика.
Не лишним будет узнать о правилах деперсонализации, принятых у Заказчика. Так как разработчики проверяют интеграции на промежуточных (тестовых) серверах, туда не должны попадать конфиденциальные данные, относящиеся к коммерческой тайне. Вероятнее всего на этапе проектирования необходимо будет заложить работы по шифрованию данных для обеспечения требований по защите информации.
ИСХОДНЫЕ ДАННЫЕ
Плавно переходим от интеграций к «чистоте» исходных данных. Так как чаще всего в ходе реализации проекта необходима интеграция более чем с одной АС, то может сложиться ситуация, когда в 2 системах могут быть справочники одинаковых сущностей (например местоположений) с разным наполнением. В таком случае нужно определить мастер-справочник, чтобы потом не пришлось заниматься сопоставлением значений этих сущностей.
Следующим шагом будет наполнение системы «историческими» данными. И тут нужно обратить внимание Заказчика на то, что чем тщательнее они поработают над первоначальной выверкой, тем меньше проблем будет в дальнейшем в ходе эксплуатации. Необходимо убрать «no name»’ы из справочников вендоров, моделей и наименований ИТ-активов. Если вы понимаете, что в исходных данных не хватает каких-то атрибутов (например, для дальнейшего построения ФРМ), то лучше сообщить об этом сразу, т.к. сбор данных займет значительное количество времени. Также важно предварительно согласовать атрибутную модель AMDB по всем категория ИТ-активов, чтобы не пришлось осуществлять повторную загрузку данных.
После формального старта эксплуатации системы следует «заставлять» Заказчика работать в ней, иначе может сложиться ситуация, что данные перестанут вносится в условный Excel и еще не начнут нормально вестись в вашей системе и это нанесет существенный ущерб качеству данных и может повлечь за собой реальные убытки, в которых в конечном счете обвинят вас.
ПРОБЛЕМЫ ОБЩЕГО ХАРАКТЕРА
Проекты по внедрению процесса управления ИТ-активами имеют те же проблемы, как и любые другие проекты в сфере информационных технологий. Я не хочу подробно останавливаться на них, на эту тему написан не один десяток статей. Разберу лишь пару наиболее типичных для данного типа проектов.
Так как чаще всего Заказчики внедрения подобных систем являются специалистами по учету ИТ-активов, то они имеют богатый практический опыт и могут считать, что им виднее, как лучше построить процесс и реализовать его в системе, но иногда их требования противоречат методологии ITAM или влекут за собой изменения, которые не вписываются в сроки реализации проекта. Тут могу посоветовать в начале проекта прислать некое портфолио команды с перечислением успешно выполненных проектов и сертификатов, имеющихся у исполнителей. Многие Заказчики не стесняются получать обратную связь у контактных лиц, указанных в данном документе и если предыдущие похожие проекты были выполнены без нареканий, то это добавит Вам пару баллов в копилку хорошего отношения. Ну и никто не отменяет дальнейшую наработку авторитета своими действиями.
Касаемо соблюдения сроков проекта следует заложить риски на внутренние работы Заказчика. Обычно у специалистов по учету раз в год наступает бюджетный период, во время которого им будет не до взаимодействия с вами. Во избежание простоя нужно распланировать работы так, чтобы к этому моменту было достаточно собранных требований.
Последнее, на что хотел обратить внимание, это использование Scrum (или аналогов) при реализации подобных проектов. Важно убедить Заказчика, что из-за масштабности, размытых границ проекта и для обеспечения плавности перехода использование гибких методологий разработки ПО необходимо. Если функционал будет предоставлен ближе к концу проекта, то на доработку в части удобства пользования системой не останется времени.
РЕЗЮМЕ
Процесс управления ИТ-активами – очень важная составляющая бизнес-процессов любого Заказчика, но в России на текущий момент слабо развитая и не распространенная. В случае успешной реализации подобного рода проекта в крупной компании, вам могут открыться огромные перспективы по дальнейшим работам по принципу «сарафанного радио». Надеюсь, что мои рекомендации помогут избежать ошибок на начальных этапах и завершать проекты качественно и в срок.
