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

Business Intelligence: принципы, технологии, обучение

В.П. Савчук
Управляющий партнер группы компаний
«Стратегический Партнер»

В современных условиях проявляется повышенный интерес многих собственников и руководителей бизнеса к Business Intelligence, или более коротко BI. Этот короткий термин подразумевает взаимосвязанный комплекс современных методов управления бизнесом, построенный на современных информационных технологиях и позволяющий обеспечить максимальную эффективности бизнеса.
Многие топ менеджеры отечественных компаний связывают это понятие с соответствующей функциональностью современных информационных систем. И здесь кроется существенное заблуждение многих отечественных менеджеров. Дело в том, что BI начинается в мозгах топ-менеджеров компаний, а потом уже реализуется с помощью информационного продукта. Менеджеры отечественных компаний должны дорасти до понимания важности BI, а потом уже покупать адекватное программное обеспечение.
Что же входит в портфель инструментов управления, объединенных общим названием Business Intelligence?.. Статья преследует сразу две цели:
1) сформулировать принципы BI,
2) представить структуру и дать краткую характеристику инструментариев BI.

Джон Харторн — человек, который знает всё про MassChallenge. Это крупнейший в мире бизнес-инкубатор, где раз в год проводится огромный конкурс проектов. Проходит это так: сначала рассматриваются тысячи заявок, потом отбирается 125 лучших из них. Победители получают бесплатный доступ к вычислительным мощностям, офисным помещениям, спонсорам, юристам и другим вещам, нужным для резкого рывка с места.

На лекции в Digital October он рассказал, что российская команда может подать заявку, приехать в Бостон, проработать там 3 месяца, поговорить с юристами, клиентами и инвесторами, выиграть 100 тысяч долларов и поехать на своём тракторе обратно в Россию.

Это было примерно месяц назад. К нам в офис приехал Василий. Он топ-менеджер компании, производящей оборудование для театральных сцен. С порога заявил, что ему нужна MES-система или APS-система и что он еще не до конца решил, какая из них. «Почему именно MES-система?» — спросил я.

— Я уже несколько месяцев занимаюсь изучением вопроса, связанного с решением наших производственных проблем. Встречался с представителями нескольких компаний, производящих MES и APS системы. Они сказали, что их системы как раз и решают наши проблемы. Причем мне сказали, что только такие системы и способны решить наши проблемы. У вас тоже MES система?

— Нет, у нас ERP-система. Да это не важно, забудьте про эти всякие аббревиатуры. Давайте просто поговорим о ваших проблемах.

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



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

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

Итак, источник инфографики: www.blog.kissmetrics.com/fan-base/

Далее самое интересное:

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

Инфографик сервиса KISS Metrics затронул не только лучших субъектов с точки зрения подписчиков Twitter и пользователей Facebook (в топ-рейтинг которых вошли: Lady Gaga, Facebook, Rihanna, Eminem и YouTube), и ведущих мировых брендов на Facebook (в топ-рейтинг которых вошли: Coca-Cola, Starbucks и Oreo), но и показал, как поклонники в социальных сетях могут быть использованы для развития бренда, в том числе тот факт, что 64% пользователей Twitter чаще всего отдают предпочтение брендам, подписчиками которых они являются.

Если кто помнит, в первой части своей статьи о гарантиях я упоминал о «подразумеваемых гарантиях» (Implied Warranties), которые автоматически являются частью контрактов на разработку ПО, т.к. они закреплены законодательно. В британском законодательстве эти гарантии закреплены в The Sale of Goods Act 1979 и The Supply of Goods and Services Act 1982. Напомню, что к «Implied Warranties» относятся: 1) Warranty of Title, 2) Infringement Warranty, 3) Warranty of Merchantability, 4) Warranty of fitness for а specific Purpose.Мы говорили о том, что если прямо не исключить действие этих гарантий, то они будут распространяться на правоотношения в рамках этого контракта. Теперь я предлагаю рассмотреть варианты исключения действия этих подразумеваемых гарантий.

В первую очередь стоит отметить, что если мы говорим о праве Великобритании, то все исключения «warranties» должны соответствовать требованиям, которые предъявляет UTCA (Unfair Contract Terms Act 1977). В соответствии с UTCA, некоторые «implied warranties» вообще не могут быть исключены (например, «Warranty of Title»), а некоторые, могут быть исключены только целесообразно — «only if reasonable» (например, «Warranty of fitness for а specific Purpose»). Если суд придет к выводу о том, что условие об исключении гарантии идет в разрез с требованиями этого нормативного акта, то это условие будет считаться недействительным. Во избежание рисков, связанных с нарушением UTCA, и в целях обеспечения исключения максимального числа гарантийных обязательств, разработчик может воспользоваться следующей конструкцией: «Other warranties are excluded to the maximum extent permitted by law».

Привет, Хабр!

У нас есть хорошие новости (хотя для кого-то они ужасные)!

Мы сделали классную систему защиты для Java-софта. Под защитой, на данный момент, подразумевается — защита от нелегального копирования и использования (нарушение политик лицензирования).

Думаю все, кто пишет на Java, знакомы с проблемами защиты своего программного обеспечения. Очень явно видны проблемы у софт-вендоров, делающих большое (или не очень) коммерческое ПО.

В январе прошлого года я делал обзор IT-настолок, который оказался постом выбора подарков. В этом году обзор — до Нового Года, как просили в комментариях.

Раньше игры с компьютера «портировались» в настольные игры, например, так стало со Starcraft, Warcraft, Doom, Civilization, Master of Orion и кучей других шедевров.

В этом году ситуация радикально поменялась: из-за огромного распространения планшетов и мобильных телефонов с хорошей поддержкой игр, настолки стали перекочёвывать в Appstore и Android Market. Под катом обзор наиболее интересных штук этого года, пример отечественного краудсорсингового проекта и традиционный небольшой подарок всем хабражителям.

Всем привет. Я с моими коллегами работали(ем) в небольшой аутсорсинговой компании. Таких мелких компаний, предоставляющих услуги по обслуживанию инфраструктуры достаточно много, да и почти каждый Системный администратор или ИТ менеджер задумывался, а не начать ли мне подобный бизнес? Одному ли, или с партнером? Вопросов на этом этапе возникает много и я со своей позиции могу поделиться опытом по созданию подобной «конторы».
Начать хотелось бы с конца, ну или почти с конца — с написания SLA. На самом деле SLA просто необходима, даже если вы начинаете работать один и берете себе клиентов на фриланс. SLA сможет помочь вам мотивированно отказывать симпатичной секретарше в просьбе починить очередной чайник. Я конечно же утрирую, но истина не так далека от примера с чайником. Если вы хотите предоставлять конвеерные услуги, т.е. такие, которые бы были идентичны от клиента к клиенту, то SLA вам в руки. Его можно называть как угодно: доп. соглашением, соглашением уровня сервиса или просто приложением к договору.
Собственно мы столкнулись с задачей по написанию SLA, когда поняли, что клиенты недовольны тем, что мы не являемся по щелчку пальца и не решаем задачи по мановению волшебной палочки. Твердо решив узаконить отношения с клиентами был составлен юридически «правильный» договор и некое подобие SLA. Конечно многие ИТ менеджеры начнут кидать в меня помидоры, но все же, то что мы создали имеет право называться SLA, т.к. несет аналогичную смысловую нагрузку.

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

Вступление окончено, переходим к советам!

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

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

Внутри — сам чеклист и примеры из нашей практики.

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

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

Я юрист ИТ-компании, которая занимается разработкой мобильных приложений и базируется в СНГ, и по роду своей деятельности тесно связан с процессом подписания контрактов с Заказчиками, которые в последнее время все чаще и чаще норовят не согласиться с условиями нашего «шаблонного контракта». Вот и теперь очередной британский Заказчик требует пересмотра состава гарантийных обязательств, которые мы обычно предлагаем. Для удобства заказчика применимым правом выбрано английское право, что подразумевает определенные трудности при согласовании таких сложных условий как гарантии.

Вполне естественное желание Заказчика максимально обезопасить себя от рисков, да и менеджер по продажам настолько настойчив, требуя не тратить время на все юридические тонкости — ведь он не хочет потерять хорошего клиента и подписать договор было бы хорошо, как обычно, «вчера».

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

Уверен, что не готовы ни мы, ни любая иная отечественная компания-разработчик. И если основная задача юриста – это распознать и нивелировать правовые риски, то мне бы стоило задуматься над тем, какие гарантии мы можем предложить Заказчику, а какие оставить за бортом.
Проведя небольшое исследование, хочу поделиться своими выводами по этому поводу:

Давно подметил, что веб-проекты отличаются разными классами «свежести»…

Первой свежести

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

Для менеджера управлять развитием такого продукта, путем итераций + ТЗ, или путем работы в доверительном Scrum/Agile-режиме — приятно. Зазубрины некритичных рисков и фрагментальных сдвигов сроков сглаживаются общим ощущением надежности и жизнеспособности продукта. Менеджер горит идеями, богатеет фичами, а после регулярной реализации самых приоритетных задач получает дозу морального удовлетворения и оптимизма… и желает дальше работать в этой компании :-)

Техническая поддержка занимается исправлением незначительных ошибок, собирая в основном в приоритезированные букеты пожелания клиентов.

Короче ощущается что-то вроде благоухания и благоговения, причем это отмечают все — и топы, и менеджеры, и разработчики, и саппорт.

К сожалению, такие проекты/продукты встречаются… нечасто. Но — встречаются.

Второй свежести

Программисты всеми правдами и неправдами пытаются протиснуться и перескочить на задачи, связанные с «правильными» модулями/компонентами продукта. Там действительно порядочек, чисто и есть желание добавлять что-то новое, проявить творчество.

Введение

Мне очень нравится Дмитрий Потапенко. С ним можно найти не так много видео на Ютубе, но я пересмотрел все. Если кто не знает — это человек, владелец около 15 магазинных и ресторанных сетей, ведет бизнес в РФ, Болгарии и Чехии, под ним работают 7000 человек, суммарный оборот $140 млн в год. До кучи, в прошлом — двухкратный чемпион мира по каратэ, в 25 лет стал вице-президентом Грюндиг по СНГ.
В общем, крутой мужик.

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

Стратегия важнее тактики

Стратегические просчеты невозможно компенсировать тактическими успехами.
«О войне», фон Клаузевиц

Это же можно сказать и про проект. Выбрали десктопное приложение вместо того, чтобы писать под Web — огромный просчет. Выбрали неверную сферу и под нее угрохали огромное количество средств — никак не реализовать. Выбрали неправильный приоритет по функционалу на месяц, конкурент вас обогнал — опять же, потеря может быть критической. Выбрали неверную технологию — вместо быстрого языка PHP писать на «правильном» типа Ява — опять же потеряли стартовую скорость, еще не выйдя на орбиту.

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

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

Разберем, какой оседлать собственное подразделение разработки и добиться успеха.

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