Блог Александра Башкирова

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

выступления

Я на XI Международной Конференции "Управление проектами 2016"

Просмотров: 1364Комментарии: 0
Alib.spb.ru

5-6 декабря в Москве проходила  XI Международной Конференции "Управление проектами 2016". Я там выступал с мастер-классом “Изменения. 360 градусов. Что мы видим и чего не замечаем”.

Пересказывать мастер-класс, наверное нет смысла - он всё-таки предполагает диалог. Поэтому вынесу сюда несколько важных выводов:

Что мы зачастую упускаем из виду в изменениях?

  • Разницу между истинным и декларируемым
  • Связи и влияние факторов
  • Страх, неготовность к собственным решениям
  • Силу момента
  • Власть эмоций
  • Необходимость видеть картину целиком
  • Одновременность всего происходящего

Основные сложности проектов по изменениям:

  • Необходимость прийти к результату вопреки сопротивлению
  • Невозможность угодить всем (хотя все очень настаивают!)
  • Несогласованность приоритетов и целей: одновременность
  • Дефицит терпения, гибкости, настойчивости в достижении результата, чувства юмора и самоуважения
  • Эмоции зашкаливают у всех участников: “доколе?” у участников и “за что мне это?” у РП и команды изменений.
Собственно, весь мастер-класс был построен на том, чтобы раскрыть эти аспекты, показать на практике, “как оно работает”. Кейсы были реальные, взятые из практики. Единственное, что они были максимально обезличенные, чтобы не дискредитировать компании - источники. И мне было очень приятно, что после ко мне подошли несколько человек, с благодарностью за выступление. Это, наверное, высшая мера похвалы - когда ты не просто “рассказал в воду”, а сделал что-то, что откликается, что нужно людям.

Немного остановлюсь на самом мероприятии и его организации. Организация была на высоте. Хорошо подобранный конгресс-холл, в пешей доступности от метро. Удобный, в меру пафосный, и “деловой” - в том смысле, что там всё настраивает на деловой лад, и не отвлекает. Хорошее зонирование. Всегда - доступный чай-кофе. Free wi-fi и доступные мобильные зарядки для телефонов. Органично вписались стенды для партнеров (кстати, их было немного). Ну и по темам… по темам всё было не просто хорошо, всё было прекрасно (говорю это не потому, что я был спикером, а потому, что темы были действительно интересными). Особенно хочется отметить выступление Павла Алфёрова. Который в своей спокойной манере просто “взял и сделал” два блока. Я смотрел всё, что можно, что интересно - и остался весьма доволен по выходу с мероприятия. Из “зацепившего” еще - интересное выступление Карины Дозорновой. На любимую мной тему - “как вытащить дохлый проект и не сдохнуть”. Очень срезонировало с опытом.

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

Я на конференции “Внедрение проектного управления 2016” (Advanta Group)

27 октября 2016 года был на конференции “Внедрение проектного управления 2016”, организованной Advanta Group (http://www.advanta-group.ru). Выступал с докладом “Как бизнес приходит к необходимости внедрения проектного управления”. Слушал доклады коллег.

Коротко стенограмма доклада (отредактированная версия, она больше иллюстрирует слайды… поэтому есть смысл читать их, глядя в слайды):

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

По сути, классическим путём решения обозначенной проблемы является внедрение регулярного менеджмента. Я не буду рассматривать крайние случаи, когда строится компания типа new age - а рассмотрю самый простой, 90% имеющий место быть вариант. Но регулярный менеджмент - это очень общее понятие, поэтому рассмотрим что может из набора его инструментов помочь в текущей ситуации. Наверное, самое простое, что можно сделать - это в том или ином виде внедрить проектное управление.

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

Как известно, есть 2 основных пути развития: революция и эволюция. Каждый из этих путей имеет свои плюсы и минусы. И наверное, для некой абстрактной компании сложно сказать - какой путь будет более правильным. Тут многое зависит от тех, кто ставит цели, стоит у руля. Кто-то хочет получить мгновенные быстрые результаты, хоть в чем-то. Кто-то - отлаженный процесс на выходе. На самом деле, скорее всего - результат будет гибридом “революции” и “эволюции”, но вот процентное соотношение будет в каждом случае разное.

Далее рассмотрим, что влияет на этот баланс, на выбор процесса.

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

Но не следует думать, что внедрение ПУ всегда проходит только “сверху”. Давайте теперь поговорим об исполнителях и о том, что для них является “красной зоной”, сигнализирующей о том, что есть запрос на внедрение ПУ - снизу. Расскажу еще одну историю, из опыта.  Была некая компания, где я также работал достаточно давно. В компании была классная команда, сконцентрированная на одной цели… были некие направления деятельности. Проблема была в том, что не было выделено явных единых точек ответственности, жизнь была под лозунгом “дедлайн не пройдет”, то есть регулярный подвиг. И всё это считалось нормой.

При этом, важно отметить, “глаза замылились” как у дирекции, так и у исполнителей. Первые просто не видели проблему. Вторые - видели, но считали что это норма переходного периода, растянутого на 3 года.

В итоге, команда “пришедших” в связи с расширением бизнеса менеджеров и исполнителей достаточно быстро выявила и обострила проблематику. Было принято решение о внедрении УП, УП внедрено… примерно в это же время компания был продана большому игороку в отрасли, где были свои стандарты управления проектами. Но это уже совсем другая история.

Кстати, очень важная мысль состоит в том, что УП будет эффективно только в том случае, когда есть конфликт - борьба за ресурсы. В противном случае, скорее всего, внедрение УП не принесет желаемого эффекта.

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

Рассмотрим теперь ожидания от внедрения УП. Это важный показатель, так как не имея представления о цели и об ожиданиях, запросто можно прийти не туда.  Из практики, применительно к ожиданиям есть 2 ситуации. Первая, при которой степень зрелости организации низкая. Вторая - при которой степень зрелости высокая. Как водится, и ожидания в представленных ситуациях будут разными. При низкой степени зрелости - ожидания будут лежать в плоскости “оно само, а я тут рядом постою”, при высокой - будут требовать конкретные показатели.

Совет: при старте проекта внедрения УП, определите степень ожиданий, основные цели и подцели. Хотя бы для себя. Тогда и проект проще вести, и ориентиры будут четкие.

И тут возникает важный, ключевой вопрос. Стоит ли вообще внедрять проектное управление, или не стоит.

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

Давайте зададимся вопросом: а когда проектное управление - вредно?

В моей практике не было таких случаев, но старшие товарищи поделились шикарной историей. Некое гос.предприятие приняло решение о повышении эффективности и внедрении УП. Решение было директивным. УП внедрили, что называется “до последней копейки”. В результате… увеличился штат (создан отдел управления и поддержки проектной деятельности), увеличилось время (теперь оформляем не только по ГОСТ но и по-проектному). Спустя 2 года - ведутся разговоры о сокращении… под раздачу первыми судя по всему, пойдут те самые проектанты.

Вывод: не все УП одинаково полезно.

А теперь рассмотрим положительный пример внедрения проектного управления.

В одной организации поводом для внедрения УП было то, что сбор статуса занимал… порядка 30% по времени от всего проекта. 30% на статус - это не просто много, это неоправданно безобразно много! И еще один кейс - когда руководство устало от выдающихся достижений в проектах до такой степени, что однажды директивно “спустило” подготовленные правила игры (по сути - ввело УП), и начало жестко спрашивать за их исполнение.

Про возражения.

УП никогда не внедряется “просто так”. УП всегда внедряется через возражения. Почему возникают возражения? Потому, что кто-то недоволен, кто-то боится, кто-то ощущает угрозу… Возражения возникают и тогда, когда сотрудник понимает, что внедрение УП может пошатнуть его положение.

Далее, рассмотрим, какие бывают возражения и как с ними работать.

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

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

рациональные: например, мне возражают “кажется, что внедрение УП приведет к излишней бюрократии”. Разговариваем на языке фактов. Оцениваем время сейчас, с учётом всех рисков, оцениваем время после. Оцениваем бюрократию сейчас. Оцениваем после. Оцениваем неразбериху сейчас. И порядок после. Подводим к позитивным выводам.

Ну и в завершении расскажу о сложностях, которые подстерегают тех, кто решился на внедрение ПУ, на начальном этапе. А вот что с ними делать? Все эти сложности по большому счету, лежат либо в области неопределенности от процесса и результата, либо в области человеческих интересов. Как работать с этими сложностями? Во-первых, о них надо просто не забыть. Во-вторых, каждую сложность можно проработать антитезисом. Например, “ожидание быстрых результатов” - шикарно может быть положено в концепцию внедрения ПУ, если принять в качестве КТ выдавать некие практически используемые результаты. Например: через месяц составлен реестр проектов, через два - определены основные метрики проектов и принят проект-пилот и т.д.

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

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

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

Я на BIT-2016

Просмотров: 701Комментарии: 0
Alib.spb.ru

6 апреля 2016 года я принимал участие в Международном Форуме «Бизнес и ИТ. Вокруг ЦОД. Вокруг Облака. Вокруг IoT. Вокруг IP. Вокруг Сетей» (или BIT-2016 - http://sankt-peterburg-grand-forum-2016.ciseventsgroup.com/). Выступал с докладом "Сказочная реальность и роеальный мир ИТ-проектов".

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

Во-вторых, о докладе. Я в какой-то момент понял, что работа РП может быть разной. Может быть "в стандартных рамках", а можно подумать - и повысить эффективность работы. Вообще тема повышения эффективности поистине неисчерпаема, поэтому я взял один аспект - работу с целями, ожиданиями и возможностями. Доклад был на 15 минут, поэтому рассказывал больше тезисно. Уложился в 11 минут, и 4 минуты отвечал на вопросы.

Для интересующихся - презентация тут.

UPD: Фото тут: https://www.flickr.com/photos/a-kom_academy/sets/72157664763371624

UPD2: Новость про мероприятие, там про меня тоже немного есть: http://ciseventsgroup.com/press-sluzhba/novosti/itogi-bit-2016-v-sankt-peterburge-luchshie-praktiki-it-proektov.html

Управление проектами в ИТ. Презентация.

Просмотров: 1778Комментарии: 2
Alib.spb.ruРабота

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

Версия достаточно старая, но суть от этого не меняется - все, что там описано, применимо и сегодня - за прошедшие с момента выпуска презентации 5 лет мало что поменялось - разве что 1С шагнул вперед с точки зрения возможностей (презентация была рассчитана на руководителей проектов с использованием 1С как средства автоматизации... но, по моему мнению, это всего лишь один из вариантов. Да и 1С в презентации затронут, наверное, процентах в 10 - 90% про управление проектами как есть).

В общем, пользуйтесь - буду рад, если кому-нибудь она поможет.

Конференция “Лицензионное программное обеспечение – это просто и безопасно”

Просмотров: 1617Комментарии: 0
IT Blogs

Сегодня принимал участие в конференции-выставке "Лицензионное программное обеспечение - это просто и безопасно". В качестве выступающего на круглом столе по теме "Open Source и лицензирование ПО. Свободное программное обеспечение и коммерческие решения. Возможности и ограничения".

Рассказывал про Open Source и возможности применения свободного ПО для решения бизнес-задач. Кому интересно - презентация во вложении к этому посту.

Вкратце основная идея такова: возможность использования Open Source, Free, Freeware, ... ПО в конкретной организации определяется ее бизнес-задачами, сложностью ПО, наличием в досточном количестве специалистов и сравнением бюджета внедрения и эксплуатации с аналогичным - для случая платного ПО.

Секция была всьма интересна, так как аудитория была искренне заинтересована в диалоге, а если добавить к этому президента SPB CIO Club Максима Белоусова (а он еще на пленарном заседании - перед круглыми столами произнес зажигательную речь) в качестве модератора, и доклады Геннадия Липича (директор представительства ABBYY в РФ) и представителя Digital Design Рыдлева М. (каюсь - полностью имя не запомнил), каждый из которых излагал свои взгляды на проблему (от "идем серединным путем" - то есть находим баланс между OpenSource и пропиетарным ПО до "только пропиетарное ПО"), то круглый стол удался на 110%. Сужу хотя бы по тому, что времени на обсуждение не хватило. Один из выводов: Open Source для решения бизнес-задач использовать можно, если применить к нему схожий с коммерческим ПО метод оценки: оцениваем риски, сроки, выгоды. И принимаем решение.

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

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

Разумеется, встретил много знакомых :)

PS. Пост получился довольно cумбурным, но зато, как говорится - "по горячим следам" :)

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

Презентация (скачать: open-source-bashkirov-presentation)

В пользу бедных

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

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

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

В общем, жизнь - это вечный поиск компромисса. Во всем.

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

Contact Center Forum – тезисы одного доклада

Просмотров: 3220Комментарии: 0
IT Blogs

29 ноября в Санкт-петербурге, отеле Ambassador, состоялось мероприятие под названием Contact Center Forum.

Я выступал там с докладом "Self Service Contact Center как инструмент повышения удовлетворенности потребителей" (тот самый докладчик, информация о котором уточняется:) )

Собственно, в блоге я решил сформулировать основные тезисы выступления: вдруг кому пригодится?

Итак.

Contact Center - это инструмент для следующих целей:

  • Маркетинговых
  • Коммуникационных
  • Повышения лояльности
  • Аналитический

Классический Contact Center - это прием и обработка обращений потребителя, при этом обработка обращений происходит по заранее оговоренным правилам, в соответствии с SLA.

Создание Contact Center - это задача, которая требует определенных инвестиций. В то же время одним из инструментов повышения прибыли компании является сокращений издержек. Издержки на Contact Center можно попробовать сократить, внедрив в его работу механизмы Self Service. Или организовав Self Service Contact Center.

Что такое Self Service Contact Center с точки зрения оператора услуг? Это, в первую очередь, набор приложений (web, sms, ussd, ...), позволяющих автоматизировать работу потребителя по получению информации и(или) управления предоставленными услугами. Далее, это пополняемая база знаний, причем пополняемая она сотрудниками оператора услуг, в соответствии с определенными методиками и регламентами. И, наконец, это политики предоставления доступа к Self Service Contact Center и его использования. В целом же, SelfService Contact Center - это сервис, предоставляемый оператором услуг их потребителю.

Что такое Self Service Contact Center с точки зрения потребителя? Это персонифицированная информация, публичная информация, скорость и надежность сервиса.

Следует отметить, что Self Service Contact Center в большинстве случаев не заменяет, а дополняет традиционный Contact Center.

Кто использует Self Service Contact Center?

  • Банки
  • Телекоммуникационные компании
  • Туристические компании
  • В общем случае - провайдеры услуг

Для организации Self Service Contact Center необходимо, чтобы провайдер услуг соответствовал следующим требованиям:

  • Он должен предлагать на рынок понятный потребителю продукт
  • У продукта должен быть понятный потребителю регламент обслуживания
  • У провайдера услуг должна быть внедрена и развернута соответствующая обеспечивающая база (например, система активации телекоммуникационных сервисов)
  • Должна быть обеспечена альтернативная поддержка и доступная справка по использованию Self Service Contact Center (что подтверждает тезис о том, что Self Service Contact Center дополняет традиционный Contact Center)

Кроме этого, пользователь Self Service Contact Center также должен соответствовать некоторым требованиям, в частности:

  • У него должен быть средний уровень технической грамотности
  • Он должен уметь пользоваться базовым средством доступа к Self Service Contact Center
  • Он должен иметь четкое представление по возможностям и последовательности действий по отношению к Self Service Contact Center
  • У него должен быть высокий уровень ответственности

Технологически Self Service Contact Center может представлять собой:

  • web-сервисы (текст, графика, голос, видео) - то есть пользователь работает с сайтом (закрытой персонифицированной частью)
  • sms (пользователь формирует специальные sms, отправляя их на специальный номер)
  • ussd (пользователь формирует специальный ussd запрос)
  • special call (пользователь звонит на специальный номер и использует систему голосового меню, либо пользователь звонит на специальные номера, в зависимости от номера, на который он звонит, происходит то или иное действие)
  • special email (пользователь формирует email на специальный адрес с указанием кода дейтствия)

Инструментами для реализации Self Service Contact Center являются:

  • портальные решения
  • SMS, Email, USSD шлюзы
  • Голосовые навигационные платформы
  • Средства активации

Таким образом, Self Service Contact Center это:

  • Современное решение, позволяющее минимизировать издержки и сфокусироваться на потребителе
  • Удачное дополнение традиционного Contact Center
  • Максимальная доступность для потребителя

Self Service Contact Center используется в основном там, где необходимо массовое обслуживание потребителей.

После этого я привел один пример - управление интеллектуальными услугами, и, ответив на ряд вопросов, скрылся в рядах слушателей:)

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