Английская королева и тайна частной жизни

Этой статьей я открываю новое направление в своем блоге: я буду рассуждать о стартапах вообще, рассказывать, какая тематика конкретно у моих стартапов, и просто делиться своими мыслями о том, что происходит в IT.

Уже второй раз досрочно завершается бесплатная расдача Windows Vista и Office 2007 в рамках кампании под названием Windows Feedback Program, организованной корпорацией Microsoft, основная задача которой заключается в получении информации о том, что делают пользователи на своих компьютерах. Пользователи буквально сметают запас выделенных для мероприятия бесплатных копий продуктов, и каждый раз кампанию приходится приостанавливать раньше отведенного срока. Следует заметить, что раздаются самые топовые версии ПО, Ultimate.

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

Мне кажется, эта новость в мире (ну и в Рунете, соответственно, тоже) слегка обделена вниманием. Точнее, она, конечно, освещалась, но...

"Некоторым пользователям идея постоянной "отчетности" покажется неприемлемой, но, судя по всему, многим это же предложение придется по душе. Почему бы не принять предложение поучаствовать в Windows Feedback Program, и получить бесплатно то, что в розницу стоит почти тысячу долларов, и на вполне законном основании?"

- такого рода благодушные реплики завершают большинство новостных сообщений.

Итак, рассмотрим, что происходит, подробнее. Для участия вы сами должны установить на свой компьютер специальную программу, которая отслеживает, кроме всего прочего:

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

Перед участием в программе вы должны предоставить свое имя, пол, e-mail и почтовый адрес. Затем данными (заметьте, не обезличенными, как часто декларируют в различных privacy policy, а четко привязанными к личности участника!), которыми вы должны щедро поделиться, Microsoft и любой из его филиалов могут пользоваться любым необходимым им образом.

Для Microsoft - это коммерческое исследовательское мероприятие. А для нас, - по сути, социальный эксперимент. Что же полезного говорят нам его результаты? Позвольте, вместо ответа процитировать один старый театральный анекдот.

Говорят, однажды Бернард Шоу выразил мнение, что все женщины продажны, вопрос только в цене. Случайно узнав об этом, английская королева, решила урезонить Шоу, и при встрече с ним спросила:

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

- Да, ваше величество, я действительно однажды так сказал.

- Что, и я - тоже продажная?! - возмутилась королева.

- И вы тоже, ваше величество, - со вздохом ответил Шоу.

- Хм, и сколько же я стою?! - начала багроветь от гнева королева.

- Десять тысяч фунтов стерлингов, - подумав, сказал Шоу.

- Что, так дешево?! - удивилась королева.

- Ну, вот видите, вы уже торгуетесь, - вышел из положения драматург.

А теперь, когда стало ясно, что даже королевы имеют свою цену, поговорим о том, как этот факт может пригодиться нам, так сказать, простым стартапщикам.

Дело в том, что в результате работы, например, тех же пресловутых социальных сетей в руках компаний, ими управляющих, образуются базы данных пользовательской личной информации чудовищных объемов. Изучая такие данные, можно получать ценные статистические срезы предпочтений пользователей, проводить data mining и выявлять определенные закономерности между типами пользователей и их поведением (- вот где Business Intelligence ;)). Владение такой информацией - сильное конкурентное преимущество. А имея возможность идентифицировать пользователя, можно сильно увеличить эффективность бизнеса, адресно продвигая свои продукты. Поэтому такие базы данных - весьма лакомый кусок для всех, кто так или иначе строит свой бизнес на потребителях.

И получается, что да, эти данные, все-таки, можно продать! Ну, естественно, не сами данные, а аналитику, а именно, на их базе полученные маркетинговые отчеты. Главное пользователям дать что-то взамен, какую-то халяву. То ли это будет разрешение бесплатно пользоваться платными услугами, то ли скидка, может быть, даже денежная премия, - что угодно, вариантов множество.

А что это, скажите мне, как не еще один вариант монетизации своего успешного стартапа, набравшего приличное количество пользователей? Или еще один источник очень неплохого дохода для тех, кто уже в игре? Я считаю, что пути обратно нет. Прогрессивное сообщество первое время будет смотреть криво и плеваться, но этот процесс неизбежен. Приватные данные станут обычным товаром, а privacy policy похудеют, если не исчезут вообще. Появится понятие privacy layer. Каждый сможет продать свой первый privacy layer дешево, второй - подороже, продать третий - значит продаться с потрохами. Это как торговля органами. Дьявол уже здесь! Вы собираетесь вступить в игру, пока еще не поздно? Хотите получить дивиденды от этого нарождающегося вида бизнеса? Я - да, и я уже работаю в этом направлении.

Кстати, список источников таких огромных баз данных личной информации можно продолжить: это и интернет-магазины, через которые проходит существенное количество заказов, и сайты подписных информационных рассылок, и вообще, любые интернет-сервисы, даже сайты платежных систем. Так что, не удивляйтесь, если в один прекрасный день вы получите e-mail с предложением согласиться на изменение нескольких пунктов Privacy Policy в обмен на какой-нибудь бонус. От которого будет трудно отказаться...

Дьявол уже здесь!

more >>

Басня об "одном флаконе"

Здесь я хочу поговорить о культуре программирования на SAP-проектах. Изначально я планировал включить этот кусок в качестве небольшого лирического отступления к одному из своих ПОЧЕМУ (см. вступление к одному из первых моих постов). Но, как водится, сказать нашлось много чего.

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

Меня собеседовал какой-то начальник отдела. В какой-то момент он спросил: "А приходилось ли вам писать на ABAP-е?". Я сказал, что нет. Он поцокал языком и сообщил: "Вообще-то, без ABAP консультанту в SAP-е никуда. Стандартного функционала настолько часто не хватает, что практически в любом месте приходится хоть две строчки, но написать. А нередко и отнюдь не две." Во мне зародилось смутное подозрение, что эту работу я не получу. Потом он начал мучать меня вопросами вроде "а как нам сделать так, чтобы если в продуктив BW придет пакет лишь с парой ошибочных записей, то не надо было бы удалять и перегружать все, ведь инициализация дельты может проходить сутки?". Мне приходилось мычать или пытаться выжать из своих обширных обще-IT-шных и скудных BW-шных знаний хоть что-нибудь, что напоминает ответ. Я понял, что работу точно не получу. Но заодно и понял и другое.

Понял, что моему идеализму нет места на российском рынке специалистов по SAP Business Intelligence (это сейчас этот термин активно используется, а тогда говорили просто SAP SEM или SAP BW/SEM). Ситуация в России и тогда, и сейчас сродни вообще ситуации с любой профессией в сфере IT: нужно все и сразу, и в одном флаконе. И не важно, какая порода у конторы-интегратора: российская или западная.

Сейчас, умея ABAP-ить, и зная почти все о BW, я, скорее, соглашусь с тем начальником, но соглашусь лишь отчасти. На то место наверняка взяли BW-шника с опытом в ABAP-е. Может, он был грамотный программист, но это вряд ли. Среди "модульных" консультантов SAP я еще не видел ни одного, кто хотя бы сносно пишет на ABAP-е. Да и, вообще, на каком-нибудь языке. Основной принцип: лишь бы работало. Господа, чем ТАК писать, лучше не писать вообще! И, уважаемые работодатели, не гонитесь за тем пресловутым "одним флаконом": лучше наймите немного больше ABAP-еров и дайте им посидеть со вступительным курсом по нужному модулю. Или, хотя бы, потрудитесь проверить, как справляется "модульный" консультант с ABAP-ом, прежде, чем он начнет "колбасить" на проекте.

Практически только у профильных программистов на SAP-проектах получается качественный код. У консультантов же на входе:

• Дурной стиль кода. Например, не видел, чтобы кто-то задумывался о системном применении отступов и регистра символов, и в идентификаторах, и в ключевых словах. Тут еще употребление переносов строк, комментарии, логическое разбиение на блоки операторов и многое-многое другое. Ну, кто знает, что такое плохой стиль, - тому объяснять не надо.
• Запутанная, неочевидная логика. Усугубляется тем, что плох стиль, но это не главная причина. В стремлении к тому, чтобы "лишь бы заработало", консультант по многу раз вносит небольшие правки и пробует кусок кода, а когда он, наконец, заработал, бросает как есть, вместо того, чтобы "причесать" его.
• Бездумный Copy-Paste. Консультанту проще скопировать кусок кода откуда-нибудь еще и "подкрутить" его, чем разобраться, как он работает и понять, что из него, например, нужна только одна строчка. Или он весь, вообще, не нужен.
• "Hard-coded" подход. Например, использование выборки напрямую из таблицы через оператор SELECT, а не использование специализированного гибкого функционального модуля или класса, разработанного SAP.
• Просто неоптимальный код. Консультант не есть профессиональный ABAP-ер, поэтому просто не может знать, как проще, быстрее и эффективнее реализовать ту или иную задачу. Или делается так, что вызывается один и тот же код по многу раз, хотя достаточно и одного, но вначале. В результате, получаются хромые и кривые ABAP-убожества.
• Отсутствие обработки особых ситуаций. Хороший программист всегда учитывает, что на вход куску кода могут попасть самые различные данные или внутри него могут возникнуть ошибки. Консультант почти никогда не думает об этом. "Лишь бы работало!"

На выходе:

• Кирпич в себе. Представление о том, что делает этот нечитабельный код имеет только тот, кто его писал, да и то через некоторое время это будет весьма не факт. Чтобы модифицировать такой негибкий код, нужно прилагать чудовищные усилия, если не переписывать полностью под новые требования. Заказчик получает вещь в себе, монолитный немодифицируемый кирпич.
• Тормоза. Неоптимальный, раздутый, да мало ли еще какой может быть плохой код. А заказчик страдает, ожидая построения отчета по 20 минут или завершения обработки по несколько часов. Его, конечно, успокоят: "Ничего, все в порядке. SAP - прожорливая система. Поставьте еще один сервер, добавьте памяти, и будет вам щастье".
• Ползучие ошибки. Консультанты попробовали на паре (ну хорошо, не на паре - на тысяче, код-то неправильный!) записей - ура, все работает! Работу сдали, а потом медленно начнут проявляться "непонятные" ошибки. То на каком-то материале отчет "валится в дамп", то почему-то зависает Java-часть, то просто результаты не верные. А заказчик либо столкнется с простоем системы, либо внедрение просто затянется.

Поверьте, как правило, при той загрузке и темпах работы, что имеет "модульный" консультант, у него в голове остается очень немного места, чтобы еще при этом и хорошо программировать. И даже можно не уточнять, SAP это или не SAP. То, что я сказал выше, вполне можно приложить и к любой корпоративной информационной системе, которая внедряется в России. Лично я был свидетелем этого в той же Axapta, пардон, Microsoft Dynamics AX.

Итак, диагноз поставлен, и еще раз рефреном сформулирую лечение:

Забудьте про "флаконы", не умножайте зло для заказчиков, не плодите проблемы для своих же внедрений. Пора пользоваться услугами профессиональных консультантов и профессиональных программистов!

А пока мы имеет то, что я еще неоднократно буду ссылаться на этот пост в своих последующих ПОЧЕМУ :)

more >>

Знакомьтесь, это - SAP BW, OLTP-система (проект РЖД №1: ЧТО)

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

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

На данный момент, у меня в голове находится концепция серии заметок, когда каждая из них будет отвечать на один из вопросов "ЧТО автоматизировалось", "КАК шло внедрение", "ПОЧЕМУ оно так шло" и "как было БЫ, если бы внедрение шло по-другому".

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

Итак, к первому ЧТО.

Задачка такая. РЖД. Вагоны регулярно отправляются в рейсы. Есть некий набор станций, на которых происходит передача вагонов от одной организации к другой. При передаче для каждого вагона составляется документ, в котором фиксируется номер вагона, а также дата и время его передачи. Каждая организация, и сдающая, и принимающая, составляет свой такой документ. В целом, организаций в процесс вовлечено много, и вагон в каждом рейсе может несколько раз передаваться между ними. А потом возникает вопрос, кто сколько должен РЖД за пользование вагоном. Плата рассчитывается на основе времени пробега. В установленные сроки все организации отсылают свои документы за прошедший отчетный период (месяц) в одно из расчетных подразделений РЖД, где и производится начисление. Технически документы организации за один отчетный период попадают в РЖД в электронном виде, грубо говоря, как массив данных вида вагон-период-дата-время.

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

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

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

Что же хотел заказчик от автоматизации? До внедрения несколько целых подразделений занимались перелопачиванием поистине гигантских объемов информации. За каждым компьютером сидел человек с двумя окнами Microsoft® Excel, в каждом из которых было открыто по массиву данных, и глазами искал "несходки". Иногда надо свериться с распечаткой, иногда - залезть в специализированную информационную систему РЖД. Хотелось, чтобы была создана система, умеющая формировать отчеты, в которые бы попадали "подозрительные" вагоны. Далее бы пользователи их бегло проверяли, возможно, удаляли бы из них "несправедливо оклеветанные" вагоны, и отправляли ли бы список прямиком виноватой организации. Те, в свою очередь, должны либо согласиться с претензиями (акцептовать), либо обосновать отказ от претензий, либо предложить свой вариант правды.

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

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

Читайте продолжение в следующем посте. Там я расскажу КАК было проведено внедрение.

more >>

Да, я знаю про Business Intelligence в SAP (SAP BI) больше других :)

Этот пост впервые появился на Хабре. Но, видя, как падает моя Карма на этом ресурсе, я решил переехать сюда. Все, что я думаю по этому поводу, я написал там же.

Проработав в компании REDLAB LTD. почти 2 года, я имел возможность ознакомиться с различными, доселе неведомыми мне, видами бизнеса. Я думал, что будучи уже более 6 лет консультантом в области Business Intelligence со специализацией в продуктах SAP, уж точно умею автоматизировать процессы стратегического управления на предприятиях нефтянки, розничной торговли, масс-медиа и т.д., и вроде бы, учиться уже нечему. Я ошибался :) Специфика в отраслях, в которых мне довелось поработать, есть, и существенная.

Итак, эти отрасли - железные дороги и ВУЗы :)

Но подозреваю, что многие могли подвизаться на ниве РАО РЖД, ибо его культивирует целый пласт интеграторов. Внутри этого пласта получилось, что затерялся и РЕДЛАБ. Точнее, меня и еще других консультантов от РЕДЛАБ взяла в субподряд компания Микротест, а та была субподрядчиком у компании Техносерв. За разработку протоколов взаимодействия отвечал ВНИИЖТ. В некоторых задачах участвовала наша талантливая компания ABBYY. Ну, в общем... Понамешано было прилично. Не думаю, что вся эта информация нарушает какие-либо подписаные договоры или существующие законы, я ничего не подписывал, проинформирован не был, так что пишу об этом без опаски. Кстати, я возможно, неверно истолковал всю иерархию взимодействия в этом клубке суб- и ген- подрядов, но у меня есть информация, которую еще есть время обработать, и я собираюсь опубликовать свои изыскания в ближайшее время.

Так что, в моих следующих постах ждите информации о том, как в данный момент живут подразделения РЖД и какие проблемы у них животрепещут. Как "решались" их проблемы с помощью автоматизации и что должно было быть сделано на самом деле, без "реверансов" между подрядчиками; что действительно экономило бы средства этого большого и всем нам знакомого заказчика, а что имело роль припарки мертвому.

А позже я расскажу о том, как внедряется SAP в ВУЗах. Здесь, наверно, компетенции не наработал почти никто...

Ждите новых сообщений :)

more >>