Очередной блок наших публикаций по теме IdM будет посвящен финансам. А именно двум самым сложным и болезненным темам – оценке проекта внедрения IdM и его обоснованию перед руководством.
Полная стоимость проекта IdM складывается из затрат на оборудование, лицензии ПО, работы подрядчика и команды проекта. По опыту, основные сложности связаны с оценкой стоимости работ по внедрению системы, поэтому начнем именно с этого вопроса.
Сложности с оценкой обычно возникают из-за недостаточной проработки требований к системе. В силу особенностей технологии IdM выполнить эту задачу на должном уровне без привлечения подрядчиков объективно сложно. Но убедить руководство в необходимости финансирования проекта по подготовке к внедрению еще сложнее, поэтому компания часто просто принимает риски и надеется, что они не реализуются.
Риски же довольно серьезные. В частности, они состоят в том, что подрядчик завысит стоимость работ, чтобы снизить собственные проектные риски, и тогда бюджет на проект могут вообще не согласовать. Или же наоборот – будет выдана и защищена оптимистичная оценка, но уже в ходе внедрения выяснится, что за указанный бюджет поставленные задачи решить невозможно.
Мы постараемся помочь организациям в подготовке и оценке проектов внедрения IdM: рассмотрим подробнее основные блоки работ по внедрению и факторы, которые существенно влияют на их трудоемкость.
На первом этапе, как правило, выполняется сбор и анализ требований, проектирование технического решения – словом, все примерно так же, как в проектах внедрения других информационных систем.
Он включает интервью с представителями основных заинтересованных сторон проекта, сбор данных о процессах управления доступом, информационных системах, которые находятся в границах проекта, о том, как в них осуществляется управление пользователями и каким образом можно с ними интегрироваться.
Стоимость данного этапа зависит от числа сотрудников, которых требуется опросить, и информационных систем, данные по которым требуется собрать. Его трудоемкость более-менее предсказуема, а длительность в среднем составляет 1–2 месяца.
Один из основных технических блоков работ – подключение информационных систем. Оно осуществляется на тестовых средах, предоставление которых сможет стать камнем преткновения для некоторых компаний. Тестовых сред может не быть, под них может не быть серверов, рук и т.п. Чаще всего это влияет только на сроки проекта, но может сказаться и на бюджете, например, в случае нехватки оборудования.
Зачастую для интеграции информационной системы с IdM ее требуется настроить, обеспечив интерфейсы для технического взаимодействия. Если информационная система находится на поддержке у сторонней организации, это может потребовать дополнительных затрат. Некоторые вендоры (например, «Диасофт») предоставляют требуемые технические интерфейсы, но за дополнительную плату. Даже если заказчик поддерживает систему своими силами, для обеспечения необходимых технических интерфейсов ему может не хватить времени или компетенции собственных специалистов. Это влияет и на сроки, и на бюджет проекта.
Информационные системы подключаются к IdM с помощью коннекторов. Вендор может заявлять, что у него есть готовые коннекторы ко всем вашим информационным системам, но в реальности все не так просто, и, как говорится, есть нюансы.
Информационные системы, предоставляющие стандартизованный интерфейс взаимодействия (например, AD), практически сводят к нулю риски, что готовый коннектор не подойдет. Однако существует ряд информационных систем (например, 1С и SAP), которые позволяют обеспечить различные варианты взаимодействия с IdM: выгрузки, веб-сервисы, представления в базе данных. Для вас может быть предпочтителен какой-то определенный вариант, к которому у производителя коннектора нет, и его потребуется дорабатывать/разрабатывать. А это снова время и деньги.
Тут может возникнуть масса других особенностей, которые существенно повлияют на сроки и стоимость проекта.
Интерфейс может быть стандартизованный, но предоставляться посредством интеграционной шины, что также может потребовать доработки коннектора. Если вендор адаптировал под вас свою информационную систему, стандартный коннектор может не подойти – и опять нужно будет закладывать бюджеты и время на доработку.
Немаловажную роль при подключении информационных систем к IdM играют и технические детали управления доступом к информационным системам. Зачастую они не видны на начальном этапе, но в конечном итоге приводят к увеличению объема работ. Например, когда для обеспечения доступа нового пользователя к одной информационной системе его нужно прописывать в двух других.
Порой из фокуса внимания выпадают дополнительные или встроенные операции, выполнение которых требуется от IdM. Например, если вы хотите не просто создавать новому сотруднику почтовый ящик в Exchange, а по определенным правилам выбирать хранилище для него. На одном из проектов мы столкнулись с информационной системой, в которой технически невозможно назначить пользователю более одной роли. Когда это выяснилось, пришлось полностью перепроектировать процесс управления доступом в ней, чтобы учесть процесс запроса дополнительных полномочий, которых может быть много. Таких мелочей может возникнуть довольно много, это все дополнительные работы, и не каждая система IdM может их поддержать.
С учетом указанных особенностей трудоемкость подключения информационной системы к IdM может существенно варьироваться в зависимости от инфраструктуры компании, а длительность может составлять от двух дней до двух месяцев. Как следствие, отсутствие детальной информации на этапе оценки сильно снижает ее достоверность и повышает проектные риски.
Существенный блок работ, который также может заметно отразиться на затратах проекта, – это настройка процессов подачи и согласования заявок на доступ. Если ваши процессы поддерживаются выбранным ПО, то настроить их не составляет большого труда. Но, не зная процессы досконально, можно лишь очень приблизительно оценить, насколько ПО их поддерживает. Соответственно трудно понять, нужна ли доработка и в каком объеме.
Многие проблемы автоматизации процессов связаны именно с тем, что мало кто понимает, как они в деталях работают. В результате процессы нередко приходится перенастраивать уже в ходе опытно-промышленной эксплуатации IdM. От количества неучтенных нюансов зависит масштаб переделки системы IdM. Вот на что следует обращать внимание:
Все эти элементы могут иметь свои особенности в каждой компании, и они не видны без детального погружения. Порой даже простой элемент процесса может привести к заметному изменению объема работ.
Например, если в регламенте есть правило, что заявка, не согласованная в течение двух рабочих дней, должна эскалироваться, это ставит перед IdM целый пласт вопросов: где вести производственный календарь, кто это будет делать, можно ли для получения этой информации интегрироваться с какой-либо имеющейся системой и т.д. Поэтому стоимость адаптации конкретного ПО для автоматизации процессов управления доступом (и вообще ее необходимость) можно оценить только после детальной прорисовки этих процессов. В противном случае есть риски, что автоматизацию не удастся сделать в полном объеме.
Вопреки ожиданиям пользователей, практика показывает, что отчеты редко бывают типовыми. С учетом отличий в деталях процессов (например, простого различия в атрибутах карточки сотрудника) каждый раз отчеты требуются чуть-чуть другие. Их подготовка не занимает много времени лишь при условии, что в журнале аудита системы IdM есть все необходимые данные. А оценить наличие этих данных без форм шаблонов отчетов достоверно не получится. Поэтому для оценки очень полезно иметь формы желаемых отчетов, иначе может потребоваться перенастройка или переработка аудита.
Это очень коварный блок работ проекта. В некоторых компаниях есть стандарты относительно проектной документации – перечень документов и требований к их оформлению (например, по ГОСТу). В некоторых организациях к документации подходят менее формально и удовлетворяются имеющейся у вендора документацией.
Поскольку в системе IdM настраиваются процессы конкретной организации, то штатная документация на ПО редко подходит. У вас будут свои категории пользователей – сотрудник, руководитель, владелец ресурса – у них будут определенные формы заявок, разделы интерфейса, отчеты, оповещения, и им потребуются отдельные инструкции. Также будет сложно развивать систему без пояснительной записки, взять на эксплуатацию без инструкций администратора. Иногда в дополнение к документации требуются обучающие материалы – презентации, видеоролики. Если число лиц, с которыми все эти материалы требуется согласовать, достаточно велико, разработка документации может потребовать несколько сотен человеко-дней, хотя на начальном этапе этот блок сильно недооценивают.
Эти этапы более-менее детерминированы. Основные задачи, которые могут как-то отразиться на длительности и стоимости работ, – это загрузка и связывание данных.
В системе IdM требуется наполнить все необходимые справочники, назначить ответственных на роли, наполнить каталог полномочий, настроить роли. Это можно сделать и в автоматическом режиме, тогда потребуются соответствующие данные.
Связывание карточек сотрудников с учетными записями тоже по большей части происходит автоматически, по заданным правилам. Однако всегда остается какой-то процент учетных записей, которые нужно связывать вручную. И иногда не так-то просто отыскать их владельцев.
Опытно-промышленная эксплуатация в большинстве компаний проходит в течение месяца, и по объему затрат практически всегда точно прогнозируема.
Оценка полной стоимости проекта внедрения IdM требует учета стоимости оборудования, лицензий, иногда – времени проектной команды, но эти вопросы зачастую не так трудны, как оценка работ по внедрению системы в силу сложности их расчета и одновременно – значительного влияния на успех проекта.
Я постарался собрать все основные факторы, которые существенно влияют на длительность и трудоемкость внедрения системы IdM, и надеюсь, что это поможет компаниям обратить внимание на ключевые моменты при подготовке проекта, сформулировать более полные требования, получить более качественную оценку, чтобы в конечном итоге снизить проектные риски перерасхода бюджета и человеческих ресурсов.
Через неделю постараюсь собрать для вас все лучшие практики обоснования у руководства проекта по внедрению IdM.
Полная стоимость проекта IdM складывается из затрат на оборудование, лицензии ПО, работы подрядчика и команды проекта. По опыту, основные сложности связаны с оценкой стоимости работ по внедрению системы, поэтому начнем именно с этого вопроса.
Сложности с оценкой обычно возникают из-за недостаточной проработки требований к системе. В силу особенностей технологии IdM выполнить эту задачу на должном уровне без привлечения подрядчиков объективно сложно. Но убедить руководство в необходимости финансирования проекта по подготовке к внедрению еще сложнее, поэтому компания часто просто принимает риски и надеется, что они не реализуются.
Риски же довольно серьезные. В частности, они состоят в том, что подрядчик завысит стоимость работ, чтобы снизить собственные проектные риски, и тогда бюджет на проект могут вообще не согласовать. Или же наоборот – будет выдана и защищена оптимистичная оценка, но уже в ходе внедрения выяснится, что за указанный бюджет поставленные задачи решить невозможно.
Мы постараемся помочь организациям в подготовке и оценке проектов внедрения IdM: рассмотрим подробнее основные блоки работ по внедрению и факторы, которые существенно влияют на их трудоемкость.
Обследование
На первом этапе, как правило, выполняется сбор и анализ требований, проектирование технического решения – словом, все примерно так же, как в проектах внедрения других информационных систем.
Он включает интервью с представителями основных заинтересованных сторон проекта, сбор данных о процессах управления доступом, информационных системах, которые находятся в границах проекта, о том, как в них осуществляется управление пользователями и каким образом можно с ними интегрироваться.
Стоимость данного этапа зависит от числа сотрудников, которых требуется опросить, и информационных систем, данные по которым требуется собрать. Его трудоемкость более-менее предсказуема, а длительность в среднем составляет 1–2 месяца.
Подключение информационных систем
Один из основных технических блоков работ – подключение информационных систем. Оно осуществляется на тестовых средах, предоставление которых сможет стать камнем преткновения для некоторых компаний. Тестовых сред может не быть, под них может не быть серверов, рук и т.п. Чаще всего это влияет только на сроки проекта, но может сказаться и на бюджете, например, в случае нехватки оборудования.
Зачастую для интеграции информационной системы с IdM ее требуется настроить, обеспечив интерфейсы для технического взаимодействия. Если информационная система находится на поддержке у сторонней организации, это может потребовать дополнительных затрат. Некоторые вендоры (например, «Диасофт») предоставляют требуемые технические интерфейсы, но за дополнительную плату. Даже если заказчик поддерживает систему своими силами, для обеспечения необходимых технических интерфейсов ему может не хватить времени или компетенции собственных специалистов. Это влияет и на сроки, и на бюджет проекта.
Информационные системы подключаются к IdM с помощью коннекторов. Вендор может заявлять, что у него есть готовые коннекторы ко всем вашим информационным системам, но в реальности все не так просто, и, как говорится, есть нюансы.
Информационные системы, предоставляющие стандартизованный интерфейс взаимодействия (например, AD), практически сводят к нулю риски, что готовый коннектор не подойдет. Однако существует ряд информационных систем (например, 1С и SAP), которые позволяют обеспечить различные варианты взаимодействия с IdM: выгрузки, веб-сервисы, представления в базе данных. Для вас может быть предпочтителен какой-то определенный вариант, к которому у производителя коннектора нет, и его потребуется дорабатывать/разрабатывать. А это снова время и деньги.
Тут может возникнуть масса других особенностей, которые существенно повлияют на сроки и стоимость проекта.
Интерфейс может быть стандартизованный, но предоставляться посредством интеграционной шины, что также может потребовать доработки коннектора. Если вендор адаптировал под вас свою информационную систему, стандартный коннектор может не подойти – и опять нужно будет закладывать бюджеты и время на доработку.
Немаловажную роль при подключении информационных систем к IdM играют и технические детали управления доступом к информационным системам. Зачастую они не видны на начальном этапе, но в конечном итоге приводят к увеличению объема работ. Например, когда для обеспечения доступа нового пользователя к одной информационной системе его нужно прописывать в двух других.
Порой из фокуса внимания выпадают дополнительные или встроенные операции, выполнение которых требуется от IdM. Например, если вы хотите не просто создавать новому сотруднику почтовый ящик в Exchange, а по определенным правилам выбирать хранилище для него. На одном из проектов мы столкнулись с информационной системой, в которой технически невозможно назначить пользователю более одной роли. Когда это выяснилось, пришлось полностью перепроектировать процесс управления доступом в ней, чтобы учесть процесс запроса дополнительных полномочий, которых может быть много. Таких мелочей может возникнуть довольно много, это все дополнительные работы, и не каждая система IdM может их поддержать.
С учетом указанных особенностей трудоемкость подключения информационной системы к IdM может существенно варьироваться в зависимости от инфраструктуры компании, а длительность может составлять от двух дней до двух месяцев. Как следствие, отсутствие детальной информации на этапе оценки сильно снижает ее достоверность и повышает проектные риски.
Бизнес-процессы
Существенный блок работ, который также может заметно отразиться на затратах проекта, – это настройка процессов подачи и согласования заявок на доступ. Если ваши процессы поддерживаются выбранным ПО, то настроить их не составляет большого труда. Но, не зная процессы досконально, можно лишь очень приблизительно оценить, насколько ПО их поддерживает. Соответственно трудно понять, нужна ли доработка и в каком объеме.
Многие проблемы автоматизации процессов связаны именно с тем, что мало кто понимает, как они в деталях работают. В результате процессы нередко приходится перенастраивать уже в ходе опытно-промышленной эксплуатации IdM. От количества неучтенных нюансов зависит масштаб переделки системы IdM. Вот на что следует обращать внимание:
- Типы ИТ-пользователей – например, штатный/нештатный сотрудник. Часто они работают в рамках абсолютно разных бизнес-процессов.
- Участники процессов. Следует понимать, какие роли участвуют в процессах и откуда система получает данные о них. Например, если в процессе согласования заявки участвует руководитель, то руководители сотрудников должны быть заведены в кадровой системе или еще каким-то образом попадать в IdM.
- Дополнительные данные для процессов. Например, если в процессе требуются данные о прохождении сотрудником обучения, нужно понимать, откуда IdM будет их получать. Это либо дополнительная интеграция, либо ручной процесс.
- Маршруты согласования. Они могут быть различными для разных сотрудников, зависеть от полномочий или каких-либо внешних условий.
- Исключительные ситуации. Важно предусмотреть поведение системы для ситуаций, когда ответственный за согласование в отпуске или уволен – как ей действовать и откуда получить необходимую информацию.
- Оповещения. В рамках автоматизируемых процессов система IdM рассылает уведомления участникам. Вопрос в том, кто на каких шагах и какую информацию должен получать.
- Формы заявок. Нередко компании требуется адаптировать формы подачи или согласования заявок, например, чтобы выводить дополнительную информацию для принятия решений.
Все эти элементы могут иметь свои особенности в каждой компании, и они не видны без детального погружения. Порой даже простой элемент процесса может привести к заметному изменению объема работ.
Например, если в регламенте есть правило, что заявка, не согласованная в течение двух рабочих дней, должна эскалироваться, это ставит перед IdM целый пласт вопросов: где вести производственный календарь, кто это будет делать, можно ли для получения этой информации интегрироваться с какой-либо имеющейся системой и т.д. Поэтому стоимость адаптации конкретного ПО для автоматизации процессов управления доступом (и вообще ее необходимость) можно оценить только после детальной прорисовки этих процессов. В противном случае есть риски, что автоматизацию не удастся сделать в полном объеме.
Отчеты
Вопреки ожиданиям пользователей, практика показывает, что отчеты редко бывают типовыми. С учетом отличий в деталях процессов (например, простого различия в атрибутах карточки сотрудника) каждый раз отчеты требуются чуть-чуть другие. Их подготовка не занимает много времени лишь при условии, что в журнале аудита системы IdM есть все необходимые данные. А оценить наличие этих данных без форм шаблонов отчетов достоверно не получится. Поэтому для оценки очень полезно иметь формы желаемых отчетов, иначе может потребоваться перенастройка или переработка аудита.
Документация
Это очень коварный блок работ проекта. В некоторых компаниях есть стандарты относительно проектной документации – перечень документов и требований к их оформлению (например, по ГОСТу). В некоторых организациях к документации подходят менее формально и удовлетворяются имеющейся у вендора документацией.
Поскольку в системе IdM настраиваются процессы конкретной организации, то штатная документация на ПО редко подходит. У вас будут свои категории пользователей – сотрудник, руководитель, владелец ресурса – у них будут определенные формы заявок, разделы интерфейса, отчеты, оповещения, и им потребуются отдельные инструкции. Также будет сложно развивать систему без пояснительной записки, взять на эксплуатацию без инструкций администратора. Иногда в дополнение к документации требуются обучающие материалы – презентации, видеоролики. Если число лиц, с которыми все эти материалы требуется согласовать, достаточно велико, разработка документации может потребовать несколько сотен человеко-дней, хотя на начальном этапе этот блок сильно недооценивают.
Перевод системы в продуктивную среду и опытно-промышленная эксплуатация
Эти этапы более-менее детерминированы. Основные задачи, которые могут как-то отразиться на длительности и стоимости работ, – это загрузка и связывание данных.
В системе IdM требуется наполнить все необходимые справочники, назначить ответственных на роли, наполнить каталог полномочий, настроить роли. Это можно сделать и в автоматическом режиме, тогда потребуются соответствующие данные.
Связывание карточек сотрудников с учетными записями тоже по большей части происходит автоматически, по заданным правилам. Однако всегда остается какой-то процент учетных записей, которые нужно связывать вручную. И иногда не так-то просто отыскать их владельцев.
Опытно-промышленная эксплуатация в большинстве компаний проходит в течение месяца, и по объему затрат практически всегда точно прогнозируема.
Резюме
Оценка полной стоимости проекта внедрения IdM требует учета стоимости оборудования, лицензий, иногда – времени проектной команды, но эти вопросы зачастую не так трудны, как оценка работ по внедрению системы в силу сложности их расчета и одновременно – значительного влияния на успех проекта.
Я постарался собрать все основные факторы, которые существенно влияют на длительность и трудоемкость внедрения системы IdM, и надеюсь, что это поможет компаниям обратить внимание на ключевые моменты при подготовке проекта, сформулировать более полные требования, получить более качественную оценку, чтобы в конечном итоге снизить проектные риски перерасхода бюджета и человеческих ресурсов.
Через неделю постараюсь собрать для вас все лучшие практики обоснования у руководства проекта по внедрению IdM.