Сегодня принимал участие в конференции-выставке "Лицензионное программное обеспечение - это просто и безопасно". В качестве выступающего на круглом столе по теме "Open Source и лицензирование ПО. Свободное программное обеспечение и коммерческие решения. Возможности и ограничения".

Рассказывал про Open Source и возможности применения свободного ПО для решения бизнес-задач. Кому интересно - презентация во вложении к этому посту.

Вкратце основная идея такова: возможность использования Open Source, Free, Freeware, ... ПО в конкретной организации определяется ее бизнес-задачами, сложностью ПО, наличием в досточном количестве специалистов и сравнением бюджета внедрения и эксплуатации с аналогичным - для случая платного ПО.

Секция была всьма интересна, так как аудитория была искренне заинтересована в диалоге, а если добавить к этому президента SPB CIO Club Максима Белоусова (а он еще на пленарном заседании - перед круглыми столами произнес зажигательную речь) в качестве модератора, и доклады Геннадия Липича (директор представительства ABBYY в РФ) и представителя Digital Design Рыдлева М. (каюсь - полностью имя не запомнил), каждый из которых излагал свои взгляды на проблему (от "идем серединным путем" - то есть находим баланс между OpenSource и пропиетарным ПО до "только пропиетарное ПО"), то круглый стол удался на 110%. Сужу хотя бы по тому, что времени на обсуждение не хватило. Один из выводов: Open Source для решения бизнес-задач использовать можно, если применить к нему схожий с коммерческим ПО метод оценки: оцениваем риски, сроки, выгоды. И принимаем решение.

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

И, наконец, организация. Она - на высоте. Темы, докладчики, перерывы и время подобраны так, что с одной стороны хочется постичь великое искусство клонирования себя - чтобы посетить сразу все, что интересно, а с другой стороны - абсолютно не ощущаешь усталости. Да, и место было выбрано пафосное - отель "Балтийская звезда", комплекс Константиновского дворца в Стрельне. Красотища...

Разумеется, встретил много знакомых :)

PS. Пост получился довольно cумбурным, но зато, как говорится - "по горячим следам" :)

Кросспост из моего ИТшного блога на ITBlogs.ru

Презентация (скачать: open-source-bashkirov-presentation)

Данная статья безнадежно устарела. Оставляена для истории. Oracle таки купила SUN.Объявленная новость о покупке - далеко не состоявшийся факт. Насколько я понимаю, после того, как стороны договорились о цене, нужно договориться с кучей государственных организаций - антимонополистами и прочими подобными американскими товарищами.

Я же предлагаю пофантазировать: предположим, покупка одобрена всеми и свершилась. Oracle купил Sun. Что дальше?

Самое важное для Oracle - теперь, благодаря этой покупке, она имеет выход на рынок оборудования, заодно приобретя несколько софтовых проектов Sun - и в первую очередь платформу Java (которую, несмотря на все старания Microsoft, так и не удалось подвинуть никакому .Net).

Что касается цены, то она, скорее всего адекватна - мне почему-то кажется, что в Oracle считать умеют, причем - умеют и просчитывать вперед.

Для меня же в этой сделке интереснее всего будет проследить "софтовый курс" Sun спустя какое-то время после покупки. В частности, интересно, как будет развиваться Java, mySql, и в какую сторону пойдет развитие Open Office, будет ли (и как интенсивно) развиваться и продаваться Star Office.

Что касается "железа", то уверен, что сервера как продавались, так и будут, разве что теперь с предустановленным Oracle, и почти наверняка будут бандлы по принципу "oracle + sun = скидка", наверняка останется в прежнем виде (а, возможно, получит еще один толчок к развитию за счет нового взгляда oracle) Java, а вот насчет всего остального уверенности значительно меньше.

В частности, тот же Open Office. При том, что он есть на компьютере практически любого линуксоида (так как альтернатив, лежащих "на поверхности", просто нет - или они мне не известны), я сильно сомневаюсь, что он (в инкарнации Star Office) приносил Sun'у хорошие барыши. Для меня разработка (вернее, причины разработки) этого продукта - одна сплошная загадка (мнение, что продукт выпускается с целью "подвинуть Microsoft", у меня вызывают сомнения: разработка - штука дорогая, и на "подвижке" ее не отобъешь), при том, что продукт "правильный" и интересный. Хотя бы своей лицензией (хотя и возможностей у него для большинства повседневных операций более чем достаточно).

Что касается mySql, то на первый взгляд все выглядит более радужно: "мускул" официально коммерческий продукт, распространяемый бесплатно в некоммерческих целях. Используется в основном в вебе (и в 95% случаев в бесплатном варианте) - там, где нужно "быстро и просто". Такое позиционирование обеспечит Oracle присутствие в новом сегменте рынка БД (БД oracle для такого рода решений мягко говоря, "тяжеловата" - примерно как из пушки - по воробьям), так что в ближайшее время вряд ли стоит ожидать известий о свертывании разработки mysql.

PS. Все рассуждения, приведенные выше - исключительно мое мнение, не претендующее на истину в последней, предпоследней и вообще какой-либо инстанции. :)

Кросспост из моего ИТшного блога на ITBlogs.ru

Тема стара как мир. И не о кризисе. Местами очень даже теоретическая.

Дано: организация (заказчик ) дозрела до автоматизации. Например, некоторых бизнес-процессов, которые на данный момент не автоматизированы. Вариантов действий в глобальном смысле не так и много:

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

П. 7 - 9 пока оставим вне рассмотрения, и перейдем к п.6 - "Рассмотрение предложений" и "Выбор". Проблема в том, что очень часто (статистика взята по 5..10 моим ИТ знакомым из разных сфер основного бизнеса) декларируемые возможности не соответствуют действительности, или соответствуют в некоторых специфических условиях. Решается все, как правило, административными мерами, доработками или патчем, что либо увеличивает бюджет внедрения, либо сроки, либо трудозатраты на баголовство.

Способов борьбы с этим явлением придумано на данный момент два:

1. На этапе "Рассмотрение предложений" - "Выбор" попросить исполнителя реализовать самую заумную из имеющихся схем (бизнес-процессов) в тестовой системе, или заказчику проделать эту операцию самостоятельно (если исполнитель считает, что реализация его силами затруднена в силу трудозатратности операции, неинтересности или нежелания заниматься клиентом и/или задачей и т.д.)
2. Составить договор так, что в случае, если что-то где-то пойдет не так, как задумывалось (декларировалось продавцом), то результатом подобного действия явилась бы солидная финансовая оплеуха исполнителю или разработчику системы (если система перепродается третьими лицами)

Как вариант, может "прокатить" комбинация этих двух способов.

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

А теперь, внимание. Вопрос к коллегам: а как вы решаете подобного рода коллизии? Интересно мнение как "исполнителей", так и "заказчиков".

PS. Очень надеюсь на ответ А.Тенцера, М.Елашкина, А.Куприянова, В.Брокуса, П.Попова и всех-всех-всех (да простят меня не упомянутые лично). :D

Кросспост из моего ИТшного блога на ITBlogs.ru

В последнее время все чаще попадается на глаза реклама, обыгрывающая слово "кризис": "антикризисный удар", "антикризисное тепло", и т.д. Самое крутое - "антикризисный новый год".

Складывается ощущение, что безбашенные сотрудники PR служб, креативщики и иже с ними включились в игру под названием "сделаем из кризиса шоу".

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

Кросспост из моего ИТшного блога на ITBlogs.ru

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

• Качество самой услуги (стабильность, бесперебойность и т.д.)
• Качество сопровождения услуги
• Персонализированный подход к потребителю

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

Другое дело, что любой оператор связи идет на пересмотр тарифов не от хорошей жизни. И уж совершенно точно - не от любви к потребителю. Передел рынка (связанный с постепенным снижением цен) для оператора связи будет обозначать, что недобор по ARPU будет компенсирован за счет дополнительных сетевых сервисов - IP TV, VoIP, и прочих, базирующихся на IP (например, системы "умный дом", построенные на базе IP сети). То есть, в конечном итоге, за счет абонента. Весь вопрос в том, какую "шоколадку" предложить абоненту, чтобы он в массе подписался на дополнительные сервисы? Мне пока непонятно... Но очевидно, что операторы вынуждены будут найти такую "шоколадку", так как в противном случае их судьба - баланс на уровне выживания или уход в смежные области.

PS. Под словом "оператор" имеется в виду оператор связи, предоставляющий услуги населению. С операторами для юридических лиц, и, паче чаяния, местными операторами, а также маленькими (на один-три дома) операторами "домосетей", бизнес-центров расклад получается несколько другой.

Кросспост из моего ИТшного блога на ITBlogs.ru

Цель любого helpdesk - обеспечение единой точки контакта ИТ - бизнес, и, в рамках процесса управления инцидентами, с поправкой на SLA (для определения приоритетов), максиально быстрое разрешение поступающих запросов. Таким образом, скорость, с которой разрешается тот или иной конкретный запрос, зависит от текущей загрузки сотрудников ИТ, и от SLA инициатора запроса. (А SLA, в свою очередь, зависит от должностных обязнностей инициатора и от характера определяющего сервиса).

Таким образом, для реализации описанной выше модели с точки зрения ИТ, требуется в первую очередь определить перечень сервисов, затем проранжировать этот перечень по сложности поддержки и определить минимальное и максимальное время восстановления (либо предоставления - в случае так называемого "сервиса по запросу"), после чего ввести логическое разделение не ИТ-сотрудников на группы по отношению к каждому предоставляемому сервису. После чего внедрить эту стройную картину в жизнь. Для этого разработанная модель должна быть доведена до не-ИТ подразделений, SLA согласованы с руководством этих подразделений и руководством предприятия, helpdesk обучен... По идее, именно в этот момент и должно наступить великое счастье.

Увы! Далеко не всегда, даже когда есть единая точка контакта счастье наступает быстро и безоговорочно. (Скромно молчу про остальные случаи). Жизнь вносит свои коррективы, выражающиеся порой в довольно забавных казусах. Рассмотрим типичные ситуации для внутренней поддержки:

• "Уход от ответственности". Ситуация встречается, когда служба helpdesk, в силу тех или иных причин (ограниченность бюджета, времени, денег, ресурсов, компетенции) не имеет возможности выполнить SLA. При этом не секрет, что часто мотивация сотрудников helpdesk зависит от скорости выполнения заявок, и прочих количественных факторов (Как это ни странно, но на качественные факторы мало когда обращают внимание). Таким образом, в особо (технологически) сложных случаях, для того, чтобы не портить статистику, сотруднику helpdesk проще закрыть заявку с приемлемой причиной (например, "не предоставлены все требуемые данные"), чем разбираться с конкретной проблемой. И это явление порождает следующую ситуацию:
• "Излишняя формализация". Helpdesk, как инструмент поддержки пользователя, при фиксации и первичной классификации обращения, основывается на информации, предоставленной пользователем. Часто для сбора информации применяют автоматизированный механизм "опросных листов" или самостоятельного заполнения форм пользователем. Чрезмерная формализация этой процедуры позволяет (на вполне законных основаниях) закрыть обращение в случае малейшей ошибки в данных, предоставленных пользователем.
• "SLA в голове". Ситуация, при которой формально SLA есть, но фактически в качестве SLA используются произвольные величины, находящиеся в умах одного-двух сотрудников Helpdesk'a. Вариант: SLA вообще не прописаны, а служба поддержки работает "по понятиям", то есть SLA изменяется от обращения к обращению, или вообще может зависеть от отношения конкретного сотрудника Helpdesk к конкретному пользователю.
• "Размывание зоны ответственности". В этом случае в SLA фиксируются наиболее типовые сервисы, а обращения по нетиповым сервисам игнорируются либо "запускаются по кругу", превращая процесс в классический "футбол заявки". Как вариант, SLA по нетиповым сервисам составляется таким образом, чтобы сотрудник Helpdesk всегда имел возможность закрыть его на основании какой-либо формальной причины. (см. пункт "излишняя формализация")
• Helpdesk представляет собой одновременно первую, вторую, третью и т.д. линии поддержки. Подобная организация сводит на нет преимущества организации многоуровневой поддержки, так как в рамках подобного универсального подразделения будут находиться специалисты разного уровня, и, как следствие, запросы по одному и тому же сервису, в рамках одного SLA, будут выполняться с разной скоростью и различным качеством.

Можно возразить, что в любом Helpdesk'e на одной линии работают специалисты разного уровня. :) Так-то, оно, конечно, так, но уровень их компетенции колеблется у некого среднего уровня, и вряд ли на Helpdesk пойдет работать человек с компетенцией сетевого администратора...

• Helpdesk представляет собой "центр защиты специалистов", то есть низкоквалифицированных сотрудников, которые всеми возможным средствами пытаются не допустить общение пользователя со второй линией поддержки, и, в меру своей квалификации, решать все поступающие к ним инциденты. Обычно подобная картина перерождается в излишнюю формализацию, поскольку задача первой линии в этом случае - найти формальный повод не выполнять требуемых работ. На практике такая картина часто возникает из-за того, что неверно трактуется описанная в ITIL организация службы поддержки.
• "Полный бардак". Helpdesk не организован, но декларируется "жизнь по ITIL". Учет заявок не ведется, или половина заявок проходит вне системы учета. Формально SLA определены, но фактически об этом никто не знает. И все счастливы... (Клинический случай?)

К чему это я? Да к тому, что формально внедрив "что-то из ITIL", организовав Helpdesk, радоваться и расслабляться рано - проблемы будут, только другого порядка, возможно, решаемые более просто - по отношению к тем, которые присутствуют в ситуации, когда Helpdesk'a нет, как класса, а ITIL является магической аббревиатурой...

Кросспост из моего ИТшного блога на ITBlogs.ru

Читал дочке сказку о репке. Сказка, она на то и сказка, чтобы иметь хороший и добрый конец: репку вытащили, всё гут - все довольны. А я подумал: а что если рассмотреть сказку в контексте проекта?

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

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

"Стал дедка тянуть репку - тянет-потянет, вытянуть не может". Как обычно, самые большие сложности в проекте возникают непосредственно перед сдачей результата Заказчику. Из изначальной постановки задачи (текста сказки) в общем, не очень понятно, кто заказчик. Но учитывая, что предприятие у дедки - малое, он - и спонсор, и руководитель, и исполнитель - то скорее всего заказчик он же.

"Позвал дедка бабку". О! На проект перед самым его завершением начали подтягивать дополнительные ресурсы.

"Пришла бабка. Тянут-потянут репку, вытянуть не могут". Одно из двух: либо недостаточна квалификация ресурса, либо проект производится впервые, и никто не знает, что делать, либо дедка круто ошибся с планированием.

"Позвала бабка внучку". Началось делегирование, размывание ответственности и привлечение дополнительных ресурсов. Скорее всего - в ущерб другим проектом. (Предприятие-то малое!)

"Тянут-потянут - вытянуть не могут". В общем, известная истина: как правило, от увеличения сотрудников на проекте эффективность увеличивается, но не пропорционально их количеству.

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

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

"Позвала кошка мышку. Тянут-потянут - и вытянули репку". Судя по всему, мышка была последним членом коллектива, не вовлечённого в рабочую группу проекта. И, в контексте сказанного выше, для меня факт того, что результат достигнут, выглядит немного странно: по моему опыту, такого рода эксперименты (увеличиваем число исполнителей без всякого анализа и приложения мозга) заканчиваются довольно печально.

Что же... Сказка ложь, да в ней намёк. Всем PMам в ней урок.

PS. Если понравилось, то могу еще чего-нибудь в этом же духе изобразить.

Кросспост из моего ИТшного блога на ITBlogs.ru