А как вы думаете, чем управление активами ПО отличается от управления лицензиями? Давайте, к примеру, зайдем на сайт Microsoft, и найдем там удивительную фразу: «Управление лицензиями — это регулярный бизнес-процесс управления активами программного обеспечения в организации». Уж кто-кто, а парни из MSFT должны знать, что такое SAM. И видимо, с их точки зрения управление лицензиями – это и есть SAM.

Смотрим в стандарт ISO/IEC 19770-1: «Эффективное управление, контроль и защита активов ПО в организации». Вот как-то так. Если активами ПО управлять, то это и будет управлением активами ПО. 

А вот что про SAM говорится в IBPL: «Практика интеграции людей, процессов и технологий, которая позволяет систематически отслеживать, оценивать и управлять лицензиями ПО и использованием ПО». Правда, тут же добавляют, что «Цель SAM – сократить расходы ИТ, использование человеческих ресурсов и снизить риски соответствия требованиям регуляторов, которые наследуются от владения и управления активами ПО». Так что без этой важной оговорки практически нереально отличить, где тут управление активами ПО, а где – управление лицензиями. Хотя, надо отдать должное, в IBPL управление лицензиями определено как «процесс, контролирующий и управляющий лицензионными соглашениями».

Лично я для себя провел следующий водораздел: управление активами ПО – это такое хитрое управление лицензиями ПО, при котором мы выходим на финансовые показатели (так как финансовый аспект — это собственно то, что делает учитываемую сущность активом). Ну например. «Благодаря тому, что мы перешли на централизованную процедуру закупки, нам удалось сэкономить на ПО х миллионов». Ну или «благодаря процедурам software metering мы отказались от закупки дополнительных лицензий, что  нам  опять-таки позволило сэкономить х миллионов». То есть у нас появляются KPI, связанные с финансами.

А как бы звучала ваша версия? Особо активный получит приз - ящик пива шоколадку.

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

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

И что интересно — стали часто просить "стандартный процесс". Есть ощущение, что это тренд. Вперед, к решениям из коробки с минимальным процессным консалтингом? Рынок меняется?

Немногим ранее Дима опубликовал свои мысли по поводу измерения Incident Management’а и придумал интересную метрику (http://www.realitsm.ru/2011/12/measuring-incident-management/). Как уже говорилось, выросла она не на пустом месте, а в результате реальной потребности заказчика – в организации задумались о системе оценки персонала ИТ. Показатель по нарушению сроков инцидентов должен был войти в эту систему, и заказчика очень не устраивало то, что фактически ответственность за нарушение срока падала на последнюю рабочую группу, которая участвовала в обработке инцидента. А так как показатели должны были влиять на зарплату сотрудников, то можете себе представить, с какой аккуратностью подходили к созданию метрик. Наличие в системе одного такого «несправедливого» KPI может и революцию породить в рядах трудящихся . Метрика, предложенная Димой, хороша и проблему такого «шума» в KPI решает. Но вот незадача – чтобы такой метрикой пользоваться, надо откуда-то определенную информацию (о времени обработки каждой группой и переназначениях между группами) брать. Система автоматизации, которая используется у заказчика, такую информацию предоставить не может. Стали рассматривать варианты – можно, конечно попробовать в конфигурацию системы автоматизации определенные изменения внести, но это долго и дорого. Да и в скором времени ее планируют заменить другим продуктом. А информацию по нарушению сроков обработки инцидентов в систему измерений включать необходимо. Клинч . Думали-думали, и с менеджером процесса пришли к следующему решению: чтобы компенсировать «шум», просто снизили норматив по обработке . А вы как бы поступили? Может быть, мы прошли мимо какого-нибудь изящного решения? 

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

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

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

Что можно сказать:

1. Использование активных меток отпадает сразу же, ибо такое решение будет стоить, как чугунный мост (стоимость активных меток, если не ошибаюсь, начинается где-то от 20 USD за штуку). Да и не сильно удобно в обслуживании – бегать батарейки менять. Это если учитывать объемы в тысячах конфигурационных единиц / активов. Если же конфигурационных единиц три штуки – возможно, это наш метод . 

2. Использование пассивных меток более приятно по цене, но также имеет массу ограничений: некоторые нельзя клеить на металлические поверхности; те, которые можно – создают непрезентабельный вид, так как толстые и торчат. Не на все из них можно нанести свою собственную информацию – и добрые производители предлагают сделать это прямо на фабрике (это особенно характерно для меток в корпусе). Все они очень не любят препятствия, в которых содержится металл – расстояние уверенного приема сигнала сильно падает, сигнал становится нестабильным или пропадает вовсе. А вот если у вас тонкие офисные перегородки без этого самого металла – можно ждать сюрпризов в виде «неучтенных» конфигурационных единиц в конкретных помещениях. И настройка чувствительности считывающих устройств иногда превращается в шаманство. Красивые мечты о том, что «сейчас мы поставим RFID-ворота, будем катать тележки с оборудованием, и у нас все будет регистрироваться автоматически» разбивается о суровую реальность: то, что лежит по краям – действительно прекрасно считывается, а вот то, что запрятано глубоко – проходит незамеченным. И так далее…

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

В библиотеке лучшего опыта по управлению ИТ-активами (IBPL) есть две интересные процессные области: «Compliance» и «Legislation». Для меня проблема в том, что я пока не понимаю, для чего эти процессные области развели: в глоссарии IBPL написано, что compliance (соответствие) – это процесс соблюдения законодательных и регулирующих требований. То есть вроде бы учитывается соответствие требованиям законодательства. Для чего же тогда нужна процессная область «Legislation»? Судя по названию, она и должна описывать соответствие требованиям законодательства. Однако про Legislation в глоссарии не написано ничего. Есть упоминание в списке процессных областей (но описание не дается). Дальнейшее упоминание этих процессных областей всегда производится в связке.

Дело усугубляется тем, что в библиотеке IBPL эти две области объединили в один том, «Compliance & Legislation». Обучение тоже проводится по этим двум областям сразу, и это при том, что для каждых других процессных областей предусмотрено отдельное обучение.

Так пока и остается загадкой, для чего нужна процессная область «Legislation». В голове крутится словосочетание «соответствие и …соответствие»

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

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

Соответствию (compliance) уделяется особое внимание и в стандарте по управлению активами ПО (ISO 19770), и в библиотеке лучшего опыта по управлению ИТ-активами (IBPL). 

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

Мы на собственном опыте этого, что называется, "наелись". При изучении лицензионных соглашений выяснилось много "забавных" фактов: например, Adobe Reader при бесплатном использовании нельзя устанавливать на сервер; Infranviewer можно использовать только в некоммерческих целях, причем под "некоммерческим" понимается использование дома, а не в офисе, ну и так далее. Поэтому я теперь периодически получаю сообщения от ответственного товарища: "Миша, а вот это ПО надо удалить"

А что же происходит в крупных организациях, где перечень используемых программных продуктов в разы больше? На 99.9% уверен, что в лицензионные соглашения там особо никто и не заглядывает...

У нас (имеется ввиду Cleverics ) периодически происходят собрания, посвященные обмену опытом. Темы могут быть абсолютно разные: конкретные проекты, предметные области, различные "фенечки" при реализации и т.д. Как правило, на них присутствуют и консультанты, и тренеры. И даже генеральный директор . На моей памяти, Олег не пропустил ни разу — хотя вроде бы спектр решаемых им задач не из той области.

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

А как у вас?

      Каждый раз убеждаюсь в том, что главное в работе консультанта – это работа с людьми. Можно спроектировать прекрасный процесс и провести замечательную автоматизацию, но процесс запросто может остаться на бумаге, в реальности не работая… Организация работ по процессу – это сложно, но увлекательно и интересно. Это всегда тяжело, так как люди в любой компании склонны к сопротивлению при проведении организационных изменений. Здесь и начинается основная, на мой взгляд, работа консультанта – необходимо мотивировать людей на исполнение новых регламентов, сделать так, чтобы новые правила соблюдались.

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

Как-то раз я участвовал в вебинаре, который был посвящен управлению активами ПО (SAM). Меня очень интересовали следующие вопросы: а что, если сотрудник использует личный компьютер с пиратским ПО в интересах организации (в производственных, так сказать, целях) и что, если этого сотрудника «поймали на горячем»? Кто будет нести ответственность – сотрудник? Организация? Или все будут виноваты? К сожалению, внятного ответа так и не получил. Решил обратиться к зарубежному опыту, чтобы понять, а как у них? И вот наткнулся на любопытный документ из библиотеки IBPL – шаблон политики для использования личных персональных компьютеров в организации. В нем есть стандартные пункты, которые фиксируют ответственность сотрудника за нарушение лицензионных соглашений и «снимают» ответственность с организации. Однако есть интересный пункт, который звучит следующим образом: «Если [организация] будет признана ответственной за нарушение авторских прав на моем компьютере, я соглашаюсь возместить все штрафы, выплаченные  [организацией]». То есть, получается, что могут наказать и организацию, не смотря на то, что компьютер находится в личной собственности сотрудника.

А как у нас? Кто-нибудь сталкивался? Есть прецеденты?

И снова про метрики и иже с ними… Недавно, обсуждая создание системы метрик с заказчиком, получили очень интересный посыл от владельца процесса. Суть его высказываний сводилась к следующему: «Мне неинтересно, какие метрики вы разработаете и сколько их будет. Мне важно понимать одну простую вещь — хорошо работает процесс или плохо». Это заставило меня задуматься о том, а насколько правильную картину мира мы рисуем для менеджера и владельца процесса. Не секрет, что в каждом процессе по-хорошему бы должна быть процедура контроля, оценки и совершенствования. Что есть контроль? «Способ управления Риском, обеспечивающий достижение Бизнес-целей или соблюдение правил и процедур Процесса.» (ITIL® V3 Glossary Russian Translation v0.92, 30 Apr 2009). То есть фактически некая система наблюдений и проверки функционирования объекта управления на предмет соответствия каким-либо правилам. Для того, чтобы можно было наблюдать и проверять – нужны контрольные показатели. На мой взгляд, контрольные показатели просто обязаны иметь целевые значения, иначе это не контрольные показатели . То есть правила, на соответствие которым мы производим проверку, должны быть «трансформированы» в понятный язык контрольных показателей. Например, «Оперативность устранения нарушений в предоставлении ИТ-услуг».И, естественно, понимать, что мы будем считать под «оперативно» и «не очень». Для того, чтобы с помощью контрольных показателей производить оценку, нужны метрики, с помощью которых мы непосредственно производим измерения. Например, в нашем случае вышеприведенный показатель могут формировать 2 метрики: «Общий % инцидентов, решенных в срок» и «Среднее время решения инцидентов». То есть если с контрольным показателем связано больше, чем одна метрика – то контрольный показатель это некая функция. В нашем случае нам придется свести к единому «знаменателю» проценты и время . «Картина мира», правильно нарисованная с помощью контрольных показателей – практически неизменна (нам не надо в случае изменения процедур процесса, целей и задач менять контрольные показатели, в отличие от метрик). На мой взгляд, контрольных показателей не должно быть слишком много – и такую картинку очень хорошо демонстрировать владельцу процесса, для которого излишняя детализация не нужна (это к вопросу о том, хорошо или плохо работает процесс). А вот для менеджера такой картины будет недостаточно – ему как раз нужна система метрик, чтобы понять, в каких областях нужно прилагать дополнительные усилия. А как вы думаете?

Не могу не поделиться примером из реальной жизни – один из Asset Manager’ов делится опытом:

«Из моих текущих контрактов поддержки с DEC я сравнил серийные номера на возобновляемых контрактах с тем, что было на складе запчастей, и нашел, что на ненужную поддержку ежегодно тратится $42 755,39. Проведя аудит всех многочисленных соглашений о поддержке с DEC, я нашел двойные серийные номера, которые являлись следствием типографской ошибки, и сэкономил еще $20 000. По нашим соглашениям о поддержке с SGI я смог объединить несколько соглашений в единое соглашение, удалил повторные носители информации, которые должны были быть приобретены по каждому контракту поддержки, договорился о 6%-ой скидке и сэкономил $14 000. Поговорив с пользователями и системным администратором, я нашел неиспользуемое ПО, которые больше не нуждалось в поддержке. Это сэкономило еще $11 555,00. По нашему 5-летнему контракту экономия составила $441 551,95.»

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

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

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

По прошествии нескольких месяцев мне пришлось отказаться от услуг выбранной компании, потому что я ни разу!!! не улетел вовремя J. Либо рейс переносили, либо задерживали, либо переносили а потом еще и задерживали. За этот период я понял, что меня интересуют только 2 ключевых параметра – стоимость авиабилета и возможность вылететь just in time. Низкая стоимость билета «компенсировалась» отвратительной своевременностью вылета. Пришлось летать самолетами другой (обычной) авиакомпании, потому что к этому времени меня это начало сильно раздражать и мешать работе, да еще и альтернативный лоукостер слегка разорился и отменил часть рейсов.

И вот о чем я подумал – вот у нас есть Полезность (возможность перелета за определенную сумму денег) и Гарантия (соответствие расписанию). А что, если вывести некий средневзвешенный коэффициент отношения Гарантии к Полезности (ну или наоборот J) для оценки идентичных услуг? И еще бы пограничное значение иметь по этому коэффициенту, ниже которого опускаться нельзя.J Зная такое критичное значение, я бы уже по-другому подходил к выбору поставщиков услуг. Жаль только, что такое не считают и не публикуют.