Блин. Именно так, с большой буквы, с чувством и выражением, с желанием побиться головой. О стену, желательно - не гипроковую. Читаю пресс-релиз/рекламную листовку Некоторой Компании. И медленно ухожу в космос. Во-первых, оттого, что листовка в заголовке говорит об одном, в первом абзаце - о другом, а дальше напоминает известное разводилово - "хотите фен бесплатно? Купите 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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