Блин. Именно так, с большой буквы, с чувством и выражением, с желанием побиться головой. О стену, желательно - не гипроковую. Читаю пресс-релиз/рекламную листовку Некоторой Компании. И медленно ухожу в космос. Во-первых, оттого, что листовка в заголовке говорит об одном, в первом абзаце - о другом, а дальше напоминает известное разводилово - "хотите фен бесплатно? Купите 2 утюга и один порошок для ловли блох". Во-вторых, листовка, отправленная адресно техническому специалисту (да, несмотря на мою любовь к бизнесориентированности ИТ, я - технарь: не стоит об этом забывать) не содержит ровным счетом ничего. Ноль полезной информации. В третьих, она написана на 4 листах А4 довольно мелким шрифтом (один лист А3, напечатанный с 2 сторон и сложенный пополам). Вернее, на 3,5 - т.к. половину листа занимает тот самый заголовок. Текст рассчитан на домохозяек. Причем, даже скорее на (простите, милые дамы) - пародию на домохозяек. На лиц с ограниченным интеллектом... Детские книжки, которые рассчитаны на детей 2..3 лет, гораздо информативнее в плане формирования мировоззрения и донесения информации.

Вопрос. Вернее - несколько. Все риторические.

* неужели PR служба Некоторой Компании не в состоянии договориться хотя бы с продавцами, не говоря о ИТшниках о написании здравого текста?

* неужели в PR службу набирают людей, не способных отличить белого от черного в целом, и к организации эффективных коммуникаций в частности?

* неужели на ЭТИ листовки кто-то ведется?

* если на ЭТО никто не ведется, то как отбиваются затраты на изготовление листовок?

* неужели ЭТО не проходило утверждения перед отправкой в типографию и заказчикам?

К счастью, утешает то, что такого рода материалы все-таки встречаются нечасто. Но, блин, встречаются!

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

Этот пост - несколько необычной судьбы :) задуман он был довольно давно, а вот дописать руки дошли только сейчас. Да и жизнь подкинула нового материала в тему - но обо всем по порядку...

Как говорил Великий Классик Винни-Пух, "размышляя над Russian Open Source, меня посетила мысль - а как же и за счет чего живут и выживают разного рода дистрибутивы Linux? Тот же Linux XP, например? Или ASPLinux?"

Возьмем для примера Linux XP. Для тех, кто не в курсе - это коммерческий российский Linux. По цене 1500 руб за десктопную "коробку". (Информация с сайта LXP). По идее, суть проста и понятна: за основу дистрибутива взята Fedora Core, в дистрибутив интегрированы закрытые (или, если угодно - несвободные) компоненты. Выкини их - система перестанет быть коммерческой, получится совсем базовая Fedora. Добавь, и получишь коммерческий Linux XP. (Правда, определенное лукавство в моем утверждении все же присутствует: Linux XP несет на себе модифицированное ядро - угода юзабилити (скрываем от пользователя некоторые папки, верное отображение русских файлов в Nautilus и т.д.) При этом утверждается, что не нарушается GPL, под которой выпускается Fedora. (В баталии о лицензиях я вступать не готов, предположу, что так оно и есть - на старом сайте Linux XP вопросу лицензионной чистоты и законности было уделено довольно много внимания, так как желающих уличить их в нечистоплотности - как минимум половина Рунета. Правда, на новом сайте материалов, касающихся лицензионной политики, законности Linux XP я не нашел;впрочем, тема не о том, так что Бог с ними).

Или другие, "более свободные", дистрибутивы. Те, которые берут деньги за коробку и поддержку (классика жанра бизнес-модели Open Source). Alt Linux, ASP Linux и прочие товарищи, исповедующие принцип доступности дистрибутива без обязательной платы. То есть хочешь коробку, руководство и поддержку - плати, не хочешь - скачивай и пользуйся.

И в том, и в другом подходе есть свои плюсы и минусы. Понятно, что, если я - корпоративный пользователь, я буду платить, так как в первую очередь предмет моего интереса - грамотная поддержка (отдельный вопрос - может ли она быть обеспечена). Время решения запроса регламентировано, запросы типизируются - красота, одним словом! (Опять, таки, отметим: все это в идеальном случае; как происходит на самом деле - мне судить сложно, т.к. моя "техподдержка" - мозги коллег + форумы ((дома я сижу на ASP Linux. Не сочтите за рекламу.)) ). Еще один момент, на который наталкивает мой прирожденный скептицизм: а зачем корпоративному пользователю Linux? Вопрос риторический, и ответов на него - масса. От "не нужен, Вы что" до "это же самый реальный способ сэкономить на ПО".

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

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

Оригинал и комментарии: ITBlogs.ru

Почитав прессу, и покопавшись в памяти, пришел к интересному выводу: простая, быстрая и легкая кастомизация любой серьезной ERP (MRP, системы управления, активации и т.д) - миф, активно поддерживаемый внедренцами. В любой проект, даже в тот, где ERP ложится вроде бы "один к одному", все равно в том или ином виде включена стоимость кастомизации.

И практически в любом проекте объем работ, связанных с кастомизацией, превышает запланированный.

Причин этому можно назвать несколько:

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

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

Российская специфика, однако.

Оригинал и комментарии: ITBlogs.ru

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

Итак, история (с)А.Молль:

Капитан - адъютанту: «Как вы знаете, завтра произойдет солнечное затмение, это бывает не каждый день. Соберите личный состав в 5 часов на плацу, в походной одежде. Они смогут наблюдать это явление, а я дам им необходимые объяснения. Если будет идти дождь, то наблюдать будет нечего, в таком случае оставьте людей в казарме».

Адъютант – сержанту: «По приказу капитана завтра утром произойдет солнечное затмение в походной одежде. Капитал на плацу даст необходимые объяснения, а это бывает не каждый день. Если будет идти дождь, наблюдать будет нечего, тогда явление состоится в казарме».

Сержант – капралу: «По приказу капитана завтра утром в 5 часов затмение на плацу людей в походной одежде. Капитан даст необходимые объяснения на счет этого явления, если будет дождливо, что бывает не каждый день».

Капрал – солдатам: «Завтра в самую рань, в 5 часов, солнце на плацу произведет затмение капитана в казарме. Если будет дождливо, то это редкое явление состоится в походной одежде, а это бывает не каждый день».

Солдат - солдату: «Завтра в самую рань, по приказу капитана, в 5 часов, состоится затмение капрала на плацу в походной одежде. Если будет дождливо, то капитан даст объяснение этому явлению в казарме, что бывает не каждый день».

Забавно? Ага! А теперь - как это бывает «у нас» (в ИТ, то есть).

Совет директоров - секретарю: «Как вы знаете, современные тенденции рынка таковы, что без системы, управляющей отношением с клиентами, то есть CRM, не обходится ни одна серьезная команда. Мы работаем над этим, поэтому завтра, в 11-00, в зале для переговоров состоится собрание заинтересованных лиц, на котором будет объявлено о запуске проекта и объявлены участники команды. Перед сотрудниками выступит президент. Поэтому, если он не вернется из командировки, собрания не будет, а о времени будет сообщено дополнительно. Кстати, надо дать задание в финансовый департамент сформировать бюджет, для чего попросить помочь ИТ департамент».

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

Директор финансового департамента – менеджеру: «По приказу президента компании, началась командировка наших клиентов в ИТ департамент, поэтому выступит совет директоров, который произведет установку CRM. Мы должны проанализировать возможные затраты в случае проведения указанного мероприятия в переговорной зале».

Менеджер – сотрудникам: «Завтра, после выступления совета директоров, президент нашей компании даст комментарии относительно стоимости установки CRM в переговорной зале, чтобы дать клиентам департамента ИТ возможные затраты. Мы должны проанализировать это».

Специалист фин.департамента - ИТ-специалисту (в курилке): «Завтра в переговорной зале, президент ИТ департамента даст клиентам по CRM, чтобы установить возможные затраты. Вы должны помочь».

...вроде бы - не смешно.

Оригинал и комментарии: ITBlogs.ru

Один из самых тонких моментов при планировании проекта - оценка времени его реализации. Есть мнение, часто приводимое в качестве шутки: "Время, необходимое для реализации проекта в случае аутсорсинга, представляет собой время, заявленное партнерами, умноженное на случайное число в диапазоне от экспоненты до пи". Надо признать, что порой и при самостоятельном выполнении проекта длительность реализации (выполнения) получаются несколько больше заявленной. (На моей памяти были "долгострои", когда время выполнения проекта как самостоятельно, так и внешним подрядчиком, отличалось от расчетного раза в 2. Конечно, два - это не совсем экспонента (e=2,7), но близко. Традиционно возникает вопрос: почему? Или, в другой интерпретации: кто виноват и что делать?

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

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

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

Оригинал и комментарии: ITBlogs.ru

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

Кстати, заказчик обычно был представлен сотрудниками ИТ и бизнес-подразделений, а также руководством - то есть основными потребителями, вдохновителями и эксплуататорами продаваемой идеи/решения. Каждый из них находился в своей проблемной плоскости, соответственно, монологи и дискуссии о конкретном решении проходили, исходя из задач, стоящих перед конкретными подразделениями/пользователями.

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

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

Получается: "не внедряйте, да не внедряемы будете":)

Оригинал и комментарии: ITBlogs.ru

Любопытно, кто и как оценивает эффективность внедрения той или иной информационной системы?

Я, например, стараюсь подобрать KPI, которые в максимальной степени связаны с областью, в которой происходит автоматизация. Например, при внедрении Service Desk такими критериями будут являться время разрешения инцидента (оно, по идее, должно уменьшится) и количество претензий пользователей (оно, по идее, тоже должно уменьшится). В случае системы управления поручениями - количество совещаний, и т.д.

При этом общим правилом при выборе KPI для каждого случая является выявление и определение количественных параметров связанных с информационной системой сервисов, и их оценка - до и после внедрения.

Самый интересный вопрос, который возникает в такой ситуации - а когда (в какой момент) измерять KPI? Наиболее общий подход (и, с моей точки зрения, наиболее верный в смысле показательности) - накопление статистики за максимально большой срок и отслеживание динамики изменения требуемого индикатора. Такой подход на большом временном промежутке позволит не только сделать вывод о изменении количественных показателей, но и провести качественную оценку и оценить возможные тенденции изменения отслеживаемого показателя. Если же привести полученную статистику к некоторому базису (за него я обычно выбираю KPI "в начале пути", то есть результат самого первого измерения моего индикатора), то получим наглядную динамику: как быстро и насколько изменился KPI.

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

Оригинал и комментарии: ITBlogs.ru