КаБа

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

Беседа с Алексеем Мареем, главным управляющим директором Альфа-Банка Случайные люди топ-позиции не занимают. Это первая мысль, с которой я хочу начать эту запись. Вторая: людей, которые объединяют в себе способности синтезировать нетривиальные идеи и быть при этом сильными менеджерами - единицы. Их надо уметь находить, чтобы учиться у них видеть мир и происходящее в нем чуть иначе. Просто в том мире, который нам может казаться скучным и унылым, на самом деле происходит много всего такого, за что можно ухватиться и развить так, чтобы жизнь стала интереснее. И благодаря этому не просто что-то сделать, а добиться выдающегося результата. На этом перехожу к конкретике - выдержки из интервью человека, управляющего банком, который создал одно из самых эффективных ДБО на российском рынке. Перенес к себе потому, что для меня эти моменты имеют важное значение. Хочу иметь их рядом. 1. Про изменения взаимоотношений между клиентом и банком: Мы не можем не замечать того, что происходит в

На мой взгляд - это очень правильная презентация о том, что надо делать для того, чтобы заниматься тем, что доставляет удовольствие, и за счет этого добиваться успеха. Не-предпринимательство from Alexei Kapterev

Как мне кажется, на данный момент это наиболее удачная (из того, что мне удалось найти) презентация о том, что такое Omni-Channel Banking и почему за ним будущее. The Future of Omni-Channel Banking from Backbase

Снова  любопытная заметка с FutureBanking . Кстати, вполне в продолжение темы про ДБО  (в той ее части, которая о привлечении клиентов). Интересен не столько факт запуска социальной сети для инвесторов, сколько сопоставление двух фактов. Прямые цитаты: Клиентами банка в Испании является 9,4 млн человек, более трети из них пользуются мобильными банковскими сервисами. Создание сообществ по интересам, позволяющих участникам установить новые связи и деловые контакты – часть стратегии la Caixa. Иными словами, создание социальных оболочек вокруг своих сервисов позволило банку конвертировать в виртуальное пространство треть своих пользователей. При этом социализация, судя по тому, что пишут, осуществляется вцелевую на отдельные группы клиентов и заключается в предоставлении им таких инструментов общения, которые логично вытекают из их пользовательского профиля с одной стороны и вовлекают в использование дистанционных сервисов банка с другой. Это, кстати, еще и к вопросу о форми

Forbes опубликовал небольшую заметку о технологических трендах, которые определены Gartner как стратегические в 2014-м году. Вот ссылка на нее:  http://www.forbes.com/sites/peterhigh/2013/10/14/gartner-top-10-strategic-technology-trends-for-2014/ Глядя на этот список, в голову приходят разные мысли. Первое, что не удивляет, но навевает некоторую ностальгию - это видение Java Script и HTML5 в качестве базовых технологий реализации интерфейсов корпоративных решений. Идея "тонкого клиента" не нова, ей, помнится, где-то еще в 2000-м году пророчили богатые перспективы. Но тогда как-то не задалось. Сейчас же у этой темы есть все шансы на блестящее будущее. И дело даже не в том, что связка Java Script + HTML5 действительно позволяет делать очень приличные пользовательские интерфейсы. Просто этот подход очень хорошо вяжется с другими тенденциями, которые пророчит Gartner. Я имею в виду темы про сервисы и клауды. С этим трудно спорить. Развитие мобильных технологий привело к

По данным компании Morgan Stanley, к 2015 году объем рынка электронной коммерции в России достигнет 36 млрд долл., при этом его доля вырастет до 4,5% с нынешних 2%, а к 2020 году - 72 млрд долл. и 7% соответственно. Судя по тому, какие надежды возлагает бизнес-сообщество как на развитие электронной розницы, так и на дистанционное банковское обслуживание, в ближайшие два - три года стоит ожидать серьезные проекты, связанные с миграцией ИТ архитектур крупных компаний, работающих в рознице, на новую идеологическую платформу. Поэтому мне кажется интересным попробовать спрогнозировать, как могла бы выглядеть ИТ решение компании, которая решила в своем стратегическом развитии делать ставку на активное использование электронных каналов продаж своих продуктов физическим лицам. А также, если получится, выявить основные зависимости, которые будут определять целевую архитектуру. В силу определенных задача будет сформулирована на довольно абстрактном уровне, но таком, которого будет достато

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

Цели которых хотелось бы достичь в результате рассмотрения этой темы: Определить типовые ожидания Заказчика Дать рекомендации по управлению ожиданиями Заказчика Цель управления ожиданиями Заказчика - обеспечить лояльность Заказчика к Исполнителю проекта как по факту завершения проекта, так и в ходе его выполнения. Ожидания Заказчика рассматривались в следующем контексте: Контекст управления ожиданиями Заказчика Очень важный момент заключается в том, что Заказчик имеет ожидания не только относительно функциональных возможностей продукта и того эффекта, который даст его внедрение, но и относительно процессов выполнения проекта. Дело в том, что соответствие ожиданиям Заказчика в части выполнения проекта закрывает для Заказчика риски его неуспешной реализации. Управление этими ожиданиями позволяет как минимум обеспечить комфортные политические условия для работы проектной команды.

Я вот столкнулся с одним интересным явлением. Почему-то некоторые аналитики считают, что требования являются результатом анализа собранной информации. Такое мнение почти всегда приводит к тому, что аналитическая фаза проекта плавно трансформируется в пытку Заказчика на предмет "расскажи, что тебе нужно". Чем мотивирован такой подход к аналитике, понять можно. Аналитику не нужно утруждать себя придумыванием решения, а любые вопросы про полноту требований, логику работы и альтернативные варианты реализации можно списать на неадекватность Заказчика и его непонимание, чего он хочет. Но с другой стороны ведь в аналитики идут люди, которые хотят найти творческую работу. Так, по крайней мере, мне говорят ребята, которые приходят трудоустраиваться. Где тут разрыв, в принципе понятно: зачастую аналитик забывает, что требования - это текстовая / графическая модель системы. Поэтому, когда он формулирует требования, он по сути придумывает систему - ее логику, границы, особенности.

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

Я все-таки решил вернуться к старой доброй КаБе. Причина одна - уход в ЖЖ был причиной гордыни. Гордыня грех. Я каюсь. Мне потребовалось сформулировать краткое, но предельно емкое определение, что такое проект. Такое определение, которое можно было бы использовать в тех случаях, когда надо обосновать что-то такое, что касается проекта. В итоге получилась вот такая картинка:

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

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

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

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

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

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

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

Буквально десять минут назад я выложил mind map про функции руководителя проекта . Но у меня есть еще одна карта - карта функций тим лида. Тим лид - роль более тонкая, чем руководитель проекта, поэтому буду очень признателен за комментарии про эту картинку:

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