Официальный портал ИТ-директоров

Добрый день коллеги. Очень близка Позиция №2. На мой взгляд, к решению данной задачи необходимо подходить с точки зрения «Необходимой достаточности». С одной стороны понятно, что используемое ПО должно быть лицензионным (законов никто еще не отменял), с другой стороны формальный подход- лицензирования всего, что установлено либо заявлено пользователями приводит к необоснованным финансовым затратам. Необходимо достаточно четко понимать необходимость установки того или иного ПО на конкретном рабочем месте. Часто бывает, что необходимости в определенном ПО либо нет совсем, либо его можно заменить бесплатными аналогами или ПО с усеченным функционалом (например: «Просмотрщиками»), не влияя на выполнение функциональных обязанностей сотрудника. Важно также корректно рассчитывать количество необходимых «клиентских лицензий» и т.д. В любом случае имея стандартизированный и формализованный подход к использованию ПО внутри компании, получаем: во первых- уменьшение стоимости владения, а во вторых -повышение прозрачности и контроля над используемым ПО. При правильном использовании данный подход приводит как к снижению рисков при использовании и сопровождении ПО, так и к повышению информационной безопасности.

Добрый день. На мой взгляд позиции отражают величину компании. Позиция 4 - наверное характерна для мелких команий и наверное там, где численность пользователей не привышает примерно 100 человек. Здесь конечно же не целесообразен "фанатичный" подход к исполнению ИТ стандартов.
Я работаю в компании, где пользователей не менее 5000. Поэтому для себя выбираю позицию 2. Мы живём в России... Адаптация международных стандартов к правилам жизни в нашей стране просто необходима.

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

Согласен с коллегами в том, что формализовывать подход к управлению ПО необходимо, но без создания процесса ради процесса. На моем опыте "soft management" реализовывался прописыванием внутренних регламентов и стандартов в рамках как бизнес-процессов, так и возможных и действующих внутренних подразделений-заказчиков. Особенно предметным становится процесс управления ПО при разнородности структуры распространения самого ПО в организации. Неоднократно сталкивался с такой градацией: 1. стандартный пакет ПО сотрудника; 2. поддерживаемое инфраструктурное ПО (SAP, Oracle, 1C etc.); 3. специализированное ПО подразделений; 4. серверное ПО и инструменты ИТ; 5. внутренние разработки компании. Градация условная, но считаю, что имеет место быть. В плане поддержки и управления ПО очень помогает ITIL в плане работы с изменениями, релизами и т.п. Отдельно стоит выделить некоммерческое ПО, а именно процессы его внедрения и сопровождения. В данном случае формализация действий должна быть существенно выше, т.к. поддержка внедрения осуществляется, в основном, своими силами (Службой ИТ). Если подвести предварительный итог, то оптимальным вариантом управления считаю Позицию №2. Кстати, а какие средства, коллеги, Вы используете для управления ПО?

Успех в управлении ПО целиком и полностью зависит от уровня управляемости бизнес-процессами на предприятии. При низкой культуре управления до сих пор наблюдаем в основном лоскутную автоматизацию. В своей деятельности всегда стараюсь настроить клиента на первоочередное решение организационных вопросов. В идеале в каждой организации надо иметь скоординированный план развития информационной системы, предусматривающий баланс вложений в аппаратную часть, ПО и, самое главное, в управленческий персонал. Грош цена технике и ПО, если персонал не сможет решать на них свои локальные управленческие задачи.
Поэтому:
1. План развития информационной системы, в т.ч. ПО, необходим, желательно года на три.
2. План развития ПО должен соответствовать (не отставать, но и сильно не опережать) управленческим задачам.
3. И управленческие задачи, и план развития ПО должны быть формализованы внутренними нормативными документами.
А в какой форме планы будут изложены, в принципе не важно. Главное, чтобы они были реальны, актуальны и понятны управленцам

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

Приветствую Вас коллеги! Поднята интересная тематика, но не активно поддерживается членами Global CIO. Может не хочется обсуждать тему с существующей в большинстве организаций Позицией №4.
От себя скажу, что к большому сожалению текущее положение software management в части управление лицензиями (управление активами) в нашей организации соответствует Позиции №4+ или Позиции №2-. Т.е. нельзя сказать, что совсем ничего не контролируется и не мониторится, но при этом нельзя сказать, что процесс жёстко формализован. Причина банальна - приоритеты в реализации бизнес-проектов, и соответственно и ресурсы и все мысли в Бизнесе.

Как целевое значение для себя я выбрал Позиция №2 и соглашусь Илларионовым Константином - необходимо придерживаться принципа "Необходимой достаточности".

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

Коллеги! Никто не говорит об инструментариях, которые используются Вами в процессе SAM. Поделитесь опытом!
И ещё: кто всё-таки несет ответственность за данный процесс? Это отдельная должность? Это отдельная бизнес-роль какой либо должности? Как это реализовано у Вас?

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

Позиция 2. - ближе!
Существует регламент, что из ПО должно быть установлено на ПК в зависимости от должности.

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

За закупку несет ответственность один человек.
За передачу и управлением другой человек.


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

По горячим следам (личное мнение о конференции 14.03.2012)

Что, на мой взгляд, конференция дала участникам.

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

Что касается лично меня, старался сверить свои планы и действия с лидерами. С удовлетворением отметил, что в управлении ПО мы не отстаем от крупных столичных компаний, а в чем то может быть и опережаем. По крайней мере, на многие вопросы участников конференции к докладчикам, у меня были свои варианты ответов, основанные на практике обслуживания клиентов. Проблемы малого бизнеса также соотносятся с проблемами большого. Разные масштабы, а суть одна.

Отметил несколько прозвучавших на конференции советов:

1. Подготовить и держать в актуальном состоянии пакет документов на установленное ПО. На практике, когда без задержки предъявляешь проверяющим, помогает при проверках. В частности снижает вероятность изъятия компьютеров.
2. Второй совет поясню на примере: купили программу, включили в расходы, а в организации на учете нет ни одного компьютера. Надо исключить подобные ситуации.
3. Предприятие, на балансе которого находится ПО ликвидировано или приостановлена деятельность, работа (то же ведение бухгалтерии) осуществляется сотрудниками другого юридического лица. «Передаточные» документы отсутствуют. Такие ситуации тоже исключить.
4. Если есть филиалы с использованием компьютерных программ в других городах, тоже надо иметь подготовленный комплект документов на право использования ПК и ПО.



Лично мои советы по бухгалтерскому и налоговому учету компьютеров и компьютерных программ:

1. Все документы на компьютеры и ПО хранить не менее пяти лет, считая с даты списания компьютера или программы.
2. В организации должен быть документ, который называется «Учетная политика организации». Так вот, один раз разобраться с правилами бухгалтерского и налогового (это разные юридические понятия!) учета по каждому виду ПО и записать это в учетной политике. Со ссылкой на законодательство. Естественно, отслеживать соответствующие законы, при необходимости меняя учетную политику.



Резко не понравились три вещи:

1. Обсуждение в основном скатывалось к управлению лицензиями, а надо говорить об управлении жизненном циклом программы.
2. О предложении сертифицироваться на соответствие стандартам.
3. Неоднократно сквозило: ИТ-ешники все такие продвинутые и прогрессивные, остальные тупые консерваторы.



О чем хотелось бы услышать подробней и на что не получил ответа:

1. О практике совместной работы ИТ-специалистов с технологическим и коммерческим персоналом.
2. Как организуется работа, связанная с маркетингом предложений поставщиков новых технологий, ИТ-услуг, программного обеспечения.
3. Как формируются потребности в ПО и порядок принятия решения на приобретение.
4. Как планируются затраты на внедрение и сопровождение ПО, модернизацию аппаратной части.
5. Кто и как определяет бизнес-задачи, под которые приобретается программный продукт. Как происходит контроль эффективности использования программного продукта.
6. Как организуются процессы документирования операций с программным обеспечением, границы ответственности.
7. По каким принципам и кто определяет набор ПО на рабочих ПК сотрудников.
8. и т.д.

Бацюро Дмитрий Сергеевич, в продолжении темы

Почему извращения?

OTRS - как раз работает по методологии ITIL
Все 4 продукта (OCS-Inventory, LDAP, GLPI, OTRS) - могут работать совместно изначально, нужно лишь настроить.

в конечном счете, будет использован единая точка входа - OTRS

Данное решение было выбрано, согласно бизнес требованиям.

Программные продукты никто не изобретал - они есть и постоянно обновляются, сейчас вышла новая версия OTRS

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